Ubercart

There is "Inventory API and Simple Stock Levels" on the below thread if interested.

http://www.ubercart.org/contrib/132

Jim

The core stock module is very basically there just to track stock on items. By itself, it does not do the 2nd and 3rd items on your list. That's where a contrib module would have to plug in using the stock values for a product to take action on the various pages. (The contrib Alaska linked to is also a more robust solution that you would use in lieu of the core uc_stock.module.) Shawn may be able to shed a little more light on this.

It looks like the stock / inventory portion of Ubercart needs some help. I'm just getting my feet wet with this part of Ubercart so I'm a little uninformed with what is already planned.

Ideally a stock manager should have some options such as

• Ability to allow back orders or not on an item (simple flag should work)
• Track inventory on all option combinations. If a product has sizes and colors then each size/color combo needs to have inventory tracking.
• Ability to disable inventory tracking on per product basis (another flag)
• If items are back ordered, an anticipated in stock date would be nice, it's a question that is fielded very often when a product is Out of Stock.
• Ability to add a vendor sku to each option combination

Can anyone give a summary of where inventory tracking is heading in Ubercart? Is the Inventory API the emerging standard?

Thanks,

Shane.

While digging into this stock issue I ran across some database design issues that are really going to cause big problems with options, skus, stock, etc.

The Basic Problem:
The uc_product table assumes from the get go that there is a one-to-one relationship of nid -> cost, nid -> price, nid -> sku.

This causes data duplication. For example, there is two different tables that hold model information for a particular nid. The uc_product table and the uc_product_adjustment table both have a field for model. This causes problems with unique skus and which skus are mapped to which nodes.

The Hurdle
How do you accommodate products that don't have options at the same time products that do?

The Solution
I believe the solution lies in the uc_pruduct_adjustments table. It uses nid and combination as the primary key. The combination is just the serialized array of the options that product has. By moving a good chunk of the fields from uc_products to uc_product_adjustments you solve the one-to-one relationship problem.

For products that do not have any options, they just get an empty serialized array inserted as the combination (i.e. a:0:{} ).

The Benefits
Stock, sku, price, cost can now be tracked on a granular level for options as well as just regular products with no options. No duplicate SKUs. Easier for other modules to connect into the complex options without writing head spinning queries.

Yes, this is a big change, affecting probably a lot of the current UC modules in one way or another. It is necessary though for UC to scale and have granular control of products and product options.

I've attached a DB flow chart of sorts, it just helps for me to get the visual relationship between tables / fields.