126 replies to this topic

[killer-g]

How about grouping Products with the same attribute in the frontend.

I had a lifestyle shop as a customer and they wanted to group their products by colour -> e.g. red candles, pillow´s, towels.

for something like this you would probably need:
- pictures from Product with option (have a full pic(red candle) assigned to an option and a small thumb(only red colour) )
- and/or something like master products


More:
-The option selection should definitly go also in the product edit dailog.
- How about a product compare? could be needed if you staticly set options for a product. Have not really needed it yet, but some folks asked for it.
- Options Types are also urgendly needed(checkbox, radio, pic, text,...)

@HARALD : I looked at your screenshoot´s and i´m impressed ... respekt !

[jjjustinnn]

First off, thanks for listening! :everybody:

I'm not saying it is easy, but really good POS systems will allow a product 'container' which is made up of smaller components. This is the only way to acheive a product that will work for a clothing company and a computer company at the same time.
Once a 'container' product is built, each individual component can then have many attributes, such as:
- sku's to deplete stock
- weight to create a final ship weight based on components
- different images for each attribute is also very important.

Obviously all the shop owners have valid concerns. But there are currently no contribs or modules that I know of that will allow a product image to change when you select a different color. This is important to consumers to get a 'feel' for what they are buying, and it is extremely common on the web in general. Not to mention the stock level problem that a color selection creates in oSc.

The most efficient way to do this in my opinion is to create a master_product_id, which can function either as the product itself, or be populated with slave_product_id's. From there, each slave can deplete stock, add weight, have images attached.

Then a simple :cough: admin button to "build" a product and add one attribute at a time.
:-j.

[Shopsearch.dk]

I'm already running a small OsC-based shop, and trying to set up a new shop with more than 2000 different items (cloth) and all have different attributes in colour and size.

So:

Xtreme-Agency, on Jan 6 2005, 12:24 AM, said:

2. a reference field :
ie a blue short size small has a diferent reference number than a blue short size large and so on....  in that case a reference number at the product level is useless.
A store owner with only common sense

is absolutly Vital for me.

Ive been looking through all Contribs to find something to meet my needs,
but without any luck

[saborchulo]

Quote

tshirt (50 in stock)
-- Style 1 (10 in stock)
---- White
---- Large
-- Style 2 (15 in stock)
---- White
---- Medium
-- Style 3 (15 in stock)
---- Blue
---- Medium
Style 4 (10 in stock)
---- Red
---- Medium.

With that type of structure, does that mean you have an item Sku for a tshirt?
The way I invision it is having a virtual product (a container) that would house lets say:
Item: Description: Attribute#1: Attribute#2:
1234 Tshirt Large White
4567 Tshirt Medium White
8910 Tshirt Large Blue

Here the parent/virtual product/container would group these items together each with their attributes and corresponding weight, stock, cost, gpm etc. I guess what I am trying to understand is why the parent or virtual product would need stock?
In that line of business do you have just a general number over every item, like I have 5000 shorts, shorts have an sku# of 1234, I have 9000 tshirts, all shirts have a sku# of 4567?

[Hierophant]

The virtual parent item's stock total would simply be a total of its children. Simple enough to do with basic math on a computer. There are products I need to know how much is available at a glance. Most of my products are repackaged from Bulk. So I need to know how many pounds or ounces of a product exist in total for re-ordering purposes. While I do sell some clothes and that was in my example, it isn't a core business nor something I wish to focus on.

My SKUS are actually based off of quasi-ISBN numbers and are in the following format:

99W-CCCIIIIISS

99W - Is my Group Number and allows me to make a false ISBN in my software. Also signifies that the item is not an actual book to the software.

CCC - This is my sidelines category for internal inventory.

IIIII - This is the item number itself.

SS - This reflects the style, size or options on a product. With clothes, the first digit would reflect the size and the second the color. Other products would have different meanings for each digit.

Since most of my products are handmade or we purchase in bulk (i.e. Essential Oils by the gallon) and repackage, there are no UPC or EAN barcodes on our products and we had to develop our own system. I believe my system is similar to how the UPC system works but haven't really compared. Currently, I type everything but the Style digits into the Model Number Field, which is renamed Item Code, and the style digits are dealt with manually at the time of order fulfillment. Would like a system that allows the combination of the two to create a complete skew on the order form.

Of course, any system put into place should be flexible enough to deal with anyone's SKU system.

Edited by Hierophant, 22 February 2005, 17:49.

[DodgerLD]

This is the exact same problem I'm faced with.

I've come up with the following database schema so far.

products
id
title

items
id
p_id
quantity
price

product_attributes
p_id
a_id

attributes
id
name

attribute_values
id
a_id
value

item_attribute_values
i_id
av_id

With this design you can find out the attributes of a particular product (e.g. Size, Color), as well as list the attribute values for a single item (e.g. Small, Red). A quantity is also maintained for each item, and attributes and attribute values are stored in 'look-up' tables. It allows for a variable number of attributes and attribute values for each product.

The problem I currently have is mapping a users' selection of attribute values (options), to an item in the item table. One idea I guess would be to construct the item PK from attribute value ID's, e.g. P001-AV3-AV5 (where av3 = Small, av5 = Red). Then the user selections could be concatenated with the product id to form a unique item identifier. The reason I don't like this approach is due to the variable nature of product attributes; e.g. if the product had 4 or 5 attributes, the item PK would end up looking something like this: P001-AV1-AV5-AV7-AV2.

Just something to think about!

mySQL 'dump' [w/sample data]

[westkoast]

As for the Color / Size attribute stock which seems to be a huge problem for people:

1. Select Color
2. Page refreshes available size
3. Select Size
4. Click Add to cart

Add to cart button is not active untill both a "color" and "size" are available.

For smaller customers I do a simple stock table for them

id = unique id
pID = product id
sID = stype associated with that product
Sizes

id pID sID S M L XL XXL, etc

This is a very static example but number are then put int he S, M, L, XL from the admin tool. If a number goes to 0 then that option is removed automatically from the "drop down" list on a the product page.

Works very nicely for planned sites, however this woul d not work out of the box for people because it relies on a schema that would not fit the masses.

[Monk]

westkoast, on Feb 23 2005, 11:25 PM, said:

As for the Color / Size attribute stock which seems to be a huge problem for people:

1. Select Color
2. Page refreshes available size
3. Select Size
4. Click Add to cart

Add to cart button is not active untill both a "color" and "size" are available.

I recently helped set up a site that has a similar system as I've seen mentioned in this thread. Take a look at ManateeGolf.com specifically the section on Irons. We built a "dependent" attributes system in which every choice is dependent upon what you previuosly selected. The end result is a customized product with a special price. The but now button does not appear until you've made all the selections.

The site has been live for about a month and we are just now working out the bugs. Once its clean and we have worked out any issues we will post as a contribution. If anyone is interested in details, post questions and I'll let you know the details.

[clouds]

Look at this ; i think this is the must of OSC
http://forums.oscommerce.com/index.php?showtopic=140035

Ethan1701, on Nov 29 2004, 09:07 PM, said:

First off, I think the stock issue is important, but problematic.
what happens if you sell sirts, you have S,M,L,XL, in red, blue and green.
How do you then manage the stock? you'll have to make a two dimentional array in order to handle it (3 yellow L, 2 green XL, 5 white S, and so on...) I think the master product contributions could come in handy here - create a master product (shirt) with salves (one for each size) and assign them attributes (for the colors).

Now, What I think is needed (or would be nice to have) in the attributes section is:
1. configure product attributes in admin/categories.php
2. allow attribute type (radio/ checkbox, etc.)
3. very important: modify the whole Option-Value_attribute interface. What I envision is something like this: (bear with me)

When you click on admin/products_attributes.php you are brought to a page that lists all the Options (size, color, etc.), where the first one (alphabetically, whatever) is highlited, and only it's Values are visible in the Values part of the page (could be where it is now...).  in the Values table, you don't need the "Option Name" column, because you're only seeing those values of the selected Option.
Below these two tables is another table, which lists all the products that have this Option. One row per product. below the list is another row with a dropdown list of all the other products, and a button to add this product to the list. Clicking on a product in this list will open a sub-table under the item (javascript, reload the page, whatever...) with all the Values of this Option. on each row of this sub-table you'll have two radio buttons, to activate or diactivate the Value, and a textbox for added price (and added wheight, if we go there).

This view will clear all the clutter on this page, make it narrower (someone said even hi-res screens couldn't handle it the way it is), and make adding attributes far more intuitive.

That's it for now,
-Ethan

<{POST_SNAPBACK}>

[GiannaL]

I have been hunting for a way to do a combination what peufeu and monk have done in these two examples. Choice dependent attributes just as monk has done with the golf site, and also changing the product image as the attributes are chosen simular to what peufeu has done on the el modjo site. My lack of experience is the problem :-;

Would either monk or peufeu be willing to help me with this?

Gianna

peufeu, on Jan 15 2005, 09:19 PM, said:

You mean, something like that :
...
Example 3
This one is finished, you can buy

<{POST_SNAPBACK}>

Monk, on Feb 28 2005, 10:21 PM, said:

I recently helped set up a site that has a similar system as I've seen mentioned in this thread. Take a look at ManateeGolf.com specifically the section on Irons. We built a "dependent" attributes system in which every choice is dependent upon what you previuosly selected. The end result is a customized product with a special price. The but now button does not appear until you've made all the selections.

The site has been live for about a month and we are just now working out the bugs. Once its clean and we have worked out any issues we will post as a contribution. If anyone is interested in details, post questions and I'll let you know the details.

<{POST_SNAPBACK}>

[Met00]

not too complex, as I have hacked it on edu4kids store. SKU's at the attribute level. I sell paper. Every colour paper is of a different SKU. I can have a pulldown for the attribute (colours) and select the colours and then add the SKUs for that colour at the same time I add any price changes.

This requires changes in how items get printed out as well. When a SKU is made at the attribute level, the product ID is THAT SKU and the product description is the product name with a "-" and then the attribute.

So. the product would be put in with a "model" of BJ11--- and title of " 36" Roll Craft Paper "
The colours would be say
Blue | +7.20 | BJ112233
Red | +3.54 | BJ113322
Green | -1.23 | BJ112323

The person orders 1 blue and 2 red.

When the order is placed the "cart" we store:

BJ112233 1 36" Roll Craft Paper - Blue"
BJ113322 2 36" Roll Craft Paper - Red"

This is what shows up in their cart, at checkout, and order history as well as on the admin side.

This method matches the way that manufacturers store and sell their items to me, and I use over 150 manufacturers.

[Jud]

One thing is for sure, the ability to control stock of attributes needs to be improved in MS3. But also, the ability to have "groups" of attributes is also needed. I have around 1000 products that all have the same attributes, and the regular way of handling attributes just won't work! ... the attributes copier really comes in handy.

Jud

[kawagner]

One attributes thing that I don't see or I am just missing is when I need to delete an attribute that is on multiple items, I have to do this one at a time, whew I juts did one and it took forever, there has to be an easier way.

[medvid]

One problem that I am starting to recognize is that there are different types of options.

1) Attribute - like a shirt color. It is an attribute of the shirt. It makes it intrinsically different from a green shirt.
1P) The problem - A buyer thinks of it as buying a shirt and picking a color. We put them in the catalog as a shirt with a color option, but really, a green shirt and a red shirt are two different products. This is the problem shops are facing with inventory, skus, etc.

2) Feature or Add-On - like a hard drive on a computer. It is a feature that can be added to the base product.
2P) The problem - the feature is often a non-sellable inventory item. The shop may only sell full computers, not separate hard drives so the attribute system is used or a contrib like Custom Computer Creator or Custom PC Creator (equal advertising!) You really want to track this inventory just like the base product.

And of course, we all want an easy way to manage, add, edit, delete, etc.

ed

[Figster]

I would like to see attributes work easier with easy populate. One cell listing all attributes for that product. I think this could be accomplished using the osc attributes and converting to a table. All attributes have been assigned a number i.e.
Color Att Number
Black 10
Red 11
Purple 23

Size Att number
s 43
m 44
L 45

Using the osc assigned attribute number I just have one cell entitled attributes
Then in that cell I simply type 43 44 45 10 11 23

And now my product will have all of the above attributes. Also should be available in the admin section of add product. You would have to add all the attributes you want, and have the abbility to download the attribute chart or table for reference. At least then, I could have one spreadsheet of all products, and there perspective attributes to upload.

I wish I understood programing, I would try to creat this on my own.
Hopefully I made some sense.

[Hierophant]

You should really talk to the author of Easy Populate about this. The OSC development team has nothing to do with that contribution.

[tccsales]

This may not be the place to post this but i will any way.

I run a computer shop. For instance i sell graphics cards by one manufacturer, but in 64mb,128mband 256mb. The same card, manufacturer and specs. It would be nice if you could have each card set as an attibute in the other cards. I know it can be done, but my point is this. It would be nice if you could create the attributes from your current stock listing.

This would make it so simple when lets say prices altered. At present you have to alter the products price, and then alter all the attributes prices aswell. If it was worked on the product listings, you would only have to enter the 1 new price and oscommerce would automatically enter the new prices.

What could be simpler.

[Figster]

Hierophant, on May 3 2005, 03:21 PM, said:

You should really talk to the author of Easy Populate about this. The OSC development team has nothing to do with that contribution.

<{POST_SNAPBACK}>

Ok, so forgett about easy populate, lets say in the admin add product, we have an attribute key, that has assigned a numerical value to all the attributes you have already added. Osc assigned the numerical value, and if you know what that is... ie the key listing them, then a form field where you would simply type in the corisponding number for the disired attribute for that product. And, if you assinged a value to that attribute, it automaticly adds or subtracts that value. so that as I add the product number 1,
Then the discription, and in another field, all the numerical attribute values need for that product seperated by a comma ie 11,14,23,44.
No more searching through a drop down list each time you want to add an attribute. You could possibly download the attribute key and print it, for quick reference, and as you add your product memory of the numerical values would make this a breeze.

If I am posting in the wrong section, please forgive me, I would just love to see an easier way to add or update product attributes. As well as the products themselves, since they go hand in hand.

The ability to upload from a spreadsheet would make it even easier.

[palmertime]

Monk, on Feb 28 2005, 06:21 PM, said:

The site has been live for about a month and we are just now working out the bugs. Once its clean and we have worked out any issues we will post as a contribution. If anyone is interested in details, post questions and I'll let you know the details.

<{POST_SNAPBACK}>

Im interested and can't wait for this contribution. But i do have a few question: After each set of irons is configured does it change the description or SKU? Can it change the SKU as it changes the product?

Peace Out,
Palmertime

Edited by palmertime, 16 June 2005, 19:45.

[petermichaux]

Suppose you are selling rectangular sheet goods like plywood.

If the two attributes are

length
-- length_short
-- length_medium
-- length_long

width
-- width_short
-- width_medium
-- width_long

then you cannot simply have a +/- weight modifier for the various lengths and a +/- weight modifer for the various widths. You have to multiply (not add) to get the surface area to calculate the weight.

Similarly if you want to show a picture of the item so the user can see the item then there cannot be an image attached to each of the lengths and widths because that is only 6 pictures and there are 9 combinations.

I think DodgerLD's post in this thread about database schema is the way to go with and the weights and images would go in his "item" table. This schema might be a little harder to use for some things but will be easier to use for others.

Edited by petermichaux, 18 June 2005, 23:16.