Good question... I dunno what is the answer. I'll do some investigation and get back to you if I got an good answer. You should email the people at iPage as they probably could help you..
Everyone, this still remains a major limitation of osCommerce. I know there are lots of other features that are in the works, and this one is not going to be an easy one to implement I'm sure. But ask any retailer how they place orders from their vendors or distributors, and most will tell you that each and every product variation (ie color, size, etc) has a unique SKU and quantity associated with it. That's how distributors sell them and that's the only way for the retailers to keep track of them..
If osc is ever going to be usable for anything more than the small mom-and-pop store, this problem MUST be addressed! I am definitely not a programmer, and I have no idea how difficult adding this functionality would be, all I do know is that it needs to happen before osc can even be considered for the vast majority of online retailers..
This is a great program, and I have yet to find anything anywhere that rivals it's feature set, flexibilty, usability and most importantly, amazing user support forums. I just hope that it doesn't get stuck in the mud by sticking with these antiquated rules about product attributes. Without individual SKUs and quantities they're worthless! Aghhh!.
Okay I'm done ranting. Keep up the great work everyone!..
I posted the same question and I got this response from Deborah:.
Attributes section. Add attributes sorter and copier for easy addition of attributes to lots of products..
This seems a little to easy, mybe she misunderstood my post...
That will help with a lot of attribute issues ... but does not do anything for the stock issue, unfortunately..
It's on the Fun Things to Do List ... but so far I have not liked the various methods that I have used on this...
Hmm... I'm pretty new to this thing, but why is it so hard?.
I've just started learning but it doesn't look to hard... but I may be completely wrong.
In the t-shirts example, there'd be an Items table and then one of the items would be t-shirt and one of the colums could be color and another one for size... for each of these colums there'd be a separate table with the different options (red and blue for color and small, medium, large for size).. and then there'd be another column for stock that'd also accept cero without eliminating the item....
Would this be wrong because of the normalization rules for databases? like I said, I'm new to this, I hope I'm not saying some silly thing..
It is more complex than that. For example, I sell pda cases and there are multiple types of cases with multiple attributes. For example:.
Side Open, Zip, Flip.
Leather, Nylon, Leather/Nylon.
Black, Black/Blue, Brown, etc..
So, this can be quite a trick within OSC. Not simple because of the combinations. ARGH!..
Well... if I ever get to the level of code knowlegde needed for this and no-one's done it yet, I'll try to help out :P..
I don't think the problem is the number of combinations of attributes. A simple solution would be put a seperate quantity for each attribute..
However, that answers leaves other cases uncovered. For example, maybe I run a custom sweat shirt shop where I ship sweat shirts with decals that are hot pressed onto the shirt. I have a limited stock of decals and a limited stock of shirts. I have.
8 red shirts.
7 blue shirts.
10 skull and crossbones.
I need to decrease the stock of both the red shirts and the skull and crossbones decals when someone orders a red shirt with a skull and crossbones, but I don't actually have any red shirts with skulls and crossbones on them and OSC by default would only decrement the red shirts..
OSC should be able to handle at least four different models:.
1. Products don't have stock (E-books, music):.
2. Products are preassembled and each option has a specific stock: (PDA cases, Normal Clothes).
3. Products are assembled by vendor, attributes have effectively unlimited stock : (Printed Images, Dyed Shirts).
4. Products are assembled by vendor, attributes have limited stock: (Computers, Pressed Sweatshirts).
Each situation has it's own quirks and needs a slightly different database design...
It sounds like basically each unique product/attribute combo needs to be a separate product. so medium red shirts with skulls has 10 in stock, while small red shirts with skulls has 8 in stock, etc..
I had a situation similar to case number 3 above, where the store was selling items that have options of height, width, color and text. each of those options are really unique attributes that are customer created, i.e. text could be "gobbledygook" or "asdfdxse" and width could be 9.43254, etc. (think cooltext.com, though with tangible items) obviously we can't have actual attributes in the db for every possible value or combination. so what we ended up doing is creating a new product with new attributes on each order..
A drawback is that the products are inserted into the db/products_table at the "In Cart" submission, so if someone is just playing around, they can "create" 20 products in no time, thus your database can grow very large very quickly. probably more than half of the products in the db are essentially ownerless and wasted space..
However, it wouldn't be too difficult to 1) clean out the products that aren't associated with an order or a basket and, more importantly to this discussion, 2) check the stock of each attribute or product and decrease them accordingly..
Probably not the best solution, but an idea...
From what I understand, it's like a certain product becomes a sort of sub-category, like t-shirt where red, green and blue are like products inside that sub-category and so on... maybe looking at it like that, instead of a product with tons of options, will help solving it..
I can't believe how timely this forum is..
I am right now enountering this very same problem. Everything about oscommerce is great, the attributes however seems extremely overcomplicated, and not as flexible as it needs to be..
My biggest problem is not the stock issue, but has to do with only certain sizes being only available for certain colours, or various other attributes being linked..
The osc_attributes_mod2 allows for linked attributes, where one thing will be selected based on another. What I need is more complicated than this however, as I need to be able to provide an additional size section, based on the value of another selected option..
I am trying to get something going for this, but I am not the best programmer. Perhaps if anyone could help at all, perhaps even providing insite into the product attributes programming..
The originator of this thread shares the opinion I formed last year, that the single greatest failing of osC (presently) is it's simplistic handling of stock or inventory. For many stores, stock accounting must be at the attribute-combination level, not at the product level. (A shirt that comes in three colors and four sizes has twelve attribute-combinations with stock levels that need to be maintained.).
Installing my second store with osC, I find myself apologizing to the client again for this inadequacy. But I will not just complain, I intend to roll up my sleeves and come up with an improvement..
Here's what I have in mind. The product entry screen in admin will have a radio button selection for stock keeping at the product level, or at the attribute level. A store may have products with both methods. The total stock for a product will still be kept in the product record, whether or not it is also accounted for at the attribute-combination level. A new table will be introduced in the database, to maintain the stock level for each attribute-combination of the products accounted for this way..
Each time a product item is added to inventory (restocking), taken out of inventory (sold), or returned to inventory (cancel or return), the stock field in the record associated with it's attribute-combination is incremented or decremented appropriately. Every time an attribute-combination record is changed, the product level total is also adjusted so all product level stock info is accurate..
A new admin program will be needed to show the product inventory, as kept at both levels, and to permit the adjustment of the quantities when restocking and to match physical inventory..
If anyone wants to assist in this, not just watch and wait, get in touch with me...
Here's the problem you are going to run into:.
How do you handle stock outs on option values?.
If you're out of green shirts, how do you let the customer know? Is it "good enough" to let him know that you don't have any when he hits the cart page, or should you let him know as soon as he selects green?.
On the database side you'd need to add a quantity field to each attribute and a field to control the quantities to both the products and the attributes..
Then you have to look at whether the product is limited or unlimited, and if the product is limited you look at each attribute to see if it is limited or not. If the product is limited it's stock is decremented when sold, if the attribute is limited it is decremented as well. Otherwise, they are not decremented. Sounds simple enough...
What I had in mind for outage of an attribute-combination was not to display that option on the product page when the product is viewed. Granted, that requires some logic in product_info.php that filters the options display based on stock status...
Uh, it took a while for the harsh reality to sink in ....
To deal with stock outages of a product's particular attribute-combinations, I can envision only two alternatives in product_info.php for presenting the available choices. (I don't like the idea of accepting the attribute choices and then informing the customer that the chosen combination is out of stock.).
One would be to revise the second option list after each onBlur of the first option list (and so on, if there are more than two), but the performance would be quite sluggish from all the page reloads. This would unduly try the patience of customers..
The second way would be to build and present a single dropdown list of the available attribute-combinations. It's a bit less user-friendly than the multiple option lists, but it would only be mandatory for products not fully stocked in all attribute-combinations...
I am by no means an expert PHP developer, but I have written ASP code for over 3 years and basically it all the same. Right now my osCommerce is hacked beyond recognition..
I have the same problem for my store. I am building an online yarn store for my wife's business. We have one type of yarn with 20 different colors. Well, actually, we have about 100 different types of yarn with close to a 1000 colors. I am testing the limits of the products attributes. My product attributes page takes a little while to load..
I spent the better part of a weekend hacking apart the inventory control to update quantity on both the product level and attribute level. While, I have not fully tested it, it seems to be working okay for me..
To make a long story short, I used the product attribute contribution that addes the attributes to the product page. Then I added several new fields in the database for quantity, and active product attibutes. I can control whether a particular attribute is active or not, and if I sell out of a color, only that attribute is automagically made inactive..
Give me a few weeks to pull it all together and I might be able to make it a contribution. I am considering rewriting it all with a more recent release. I really want to include that security proposal that is now included with the daily snapshot...
If you've managed to get this to work, that's expert enough!.
Have you decided how to put this together as a contribution? If you don't have the time to strip out the relevent bits, perhaps you could zip up your whole store, or the relevant files, so we could have a go at that part?.
This would be a really important contribution for my site, so fingers crossed!..
Fuzzatronic / Lynda.
Has there been any more work done on this - I know this thread of attribute level stock control won't die until this issue is resolved!.
I'm just as eager to get a resolution as all the other merchants / designers out there wanting to use OsC.
Just curious if anyone has solved this attribute-quantity problem?.
I know very close to nothing about php (just what Ive learned here, putting my store together) but will assist in anyway I can.......
I could make some sugar cookies and coffee to pass around the thinking table. (wink).
Yes OSC is great and I really enjoy this program, but I want to make a clothes-outlet store and... I've reached the limit of OSC..
How ? .
Here an example:.
You got an item (T-Shirt) in 2 possible colors (red,blue) in 3 possible sizes (S, M, L) and on stock you have:.
Using OSC you can not add different stock per options, using contributions, if one of the stock of an attribute is egal 0, the whole Item is vanishing in OSC nirvana....
And then... you reached the end !.
So community, I would really appreciate that you help me doing this and I am sure we will bring OSC further than ever, helping all people outside selling clothes or items with different stock on attributes..
Agreed. This issue happens to not just be limited to those selling clothes. In the real world, "attributes" are actually separate products. They have seperate sku's, seperate upc's, seperate stock, and even seperate names.....