mc12345678:
Are you saying that if you goto the option Names Manager and look at the ID for the Color option that it has the same ID as the Bottle Size option? Are you able to provide a link to look at where this is an issue? Have you tried creating another product with those option names and values to see if the same issue carries over or if it is something that just got "created" with this product? Possibly tried to recreate the option name(s) and assign to the product, etc... ?
Sorry to not state what I considered obvious. Each Option Name has its own distinct ID, as does each Option Value. Out of the non-db-constrained unique fields, the only differences between the options is the option name and products_options.products_options_track_stock
mc12345678:
As to how the variant(s) are populated for that product, are you doing:
Stock ID:
X having color and capacity assigned with a quantity of availability for that combination and associated customid, or are you doing:
Stock ID:
X color quantity of "color" and customid (if one assigned).
Y capacity quantity of "capacity" and customid (if one assigned).
such that there is a color availability of quantity W and capacity of Z and the availability is the lesser of the two?
Doesn't exactly seem to be an issue specifically with the plugin, but something that has been discovered through its use...
Regarding the field(s), I don't see that products_options_track_stock is currently a part of this plugin. I believe that the original Dynamic Dropdowns plugin (earlier version of this plugin included it as was) included that field, but I think I removed it for the time being so that it wouldn't negatively affect databases until fully/properly incorporated.. So an earlier installation of some type may have used that data, though I can't say that I have seen (though haven't dug deep into all) a publicly available set of code that made that additional field directly accessible (ie not requiring database manipulation through external sql or phpmyadmin modification). Otherwise, only having the one "table" as the restraining location seems to me to be a little limiting, but development does have to start/go somewhere. :) At the moment though, this code does not "respect" the setting in that table field. At the same time, installation does not remove it if it is there just doesn't add it nor read it, directly.. Sure if pulls all fields from the table then it would be included, but isn't currently a part of the operation.
Stock ID:
Capacity: Slim (2.5ml) Color: Clear Qty: 3
Capacity: Slim (2.5ml) Color: Black Qty: 8
Capacity: Slim (2.5ml) Color: Blue Qty: 7
Capacity: Slim (2.5ml) Color: Orange Qty: 12
Capacity: Slim (2.5ml) Color: Pink Qty: 4
Capacity: Large (5.0ml) Color: Clear Qty: 6
Capacity: Large (5.0ml) Color: Black Qty: 10
Capacity: Large (5.0ml) Color: Blue Qty: 7
Capacity: Large (5.0ml) Color: Orange Qty: 2
Capacity: Large (5.0ml) Color: Pink Qty: 6
Capacity is one Option with Slim and Large as options values
Color is the other option with Clear, Black, Blue, Orange and Pink as options values
We track all inventory by product for products with no attributes, Product AND attribute 1 for single-option products, and Product AND attribute 1 AND attribute 2 for two-option products. There's no product in our catalog where we stock by one attribute and can change the second attribute on-the-fly.
Each SKU is unique to the products_with_attributes_stock.stock_id (items with attributes) or products.products_id (items without attributes). We have an additional module we created, which creates SKUs for each stocked item, such as
A0832075009. This number is useless to the customer, and would be confusing or irritating, but is essential to fulfilling orders, since it is broken down as such:
A - Department (shelving Unit)
08 - Shelf number
32 - Slot Number *** These three data points give the picker the precise location of the item
07 - counter - Once we no longer stock an item, the stock location is available, so the next item put in the location receives the next number in sequence
50 - Value for the first attribute, such as 50 for 5.0 ml and 25 for 2.5ml
09 - Value for the second attribute *** Once the pickers are familiar with these last two fields, they provide a sanity check to ensure the item in-hand is the right size/color, etc.
Our SKU Module updates the products.products_model OR products_with_attributes_stock.customid with our SKU, depending on whether or not the item has attributes. Our module reads a number of other tables, but only updates these two fields, since Zen Cart/SBA already use them (mostly) how we want/need them to be used. The "mostly" is my question of whether Configuration => Stock => SBA Display Custom ID = false hides the customid on pick slips and invoices *as well as *the attribute selection dropdowns and shopping cart.
I've already considered deleting and recreating the SBA tracking for this problem child. If you'd like to see the symptom before I try to dump and recreate, PM me and I can get you inside the "down for maintenance" wall.
