 |
Ubercart |
|
|
|
||
uc_stock
Submitted on Tue, 01/08/2008 - 19:00
 Hi, I couldn't find any discussion of the new uc_stock module that is included as part of version Beta 1.0. Just wondering what it does... Thanks.  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.     So, is the idea to move CpILL's stuff into the core, or to replace it by core functionality, or to provide an alternate framework for building a new inventory system, or ... ? I'm using CpILL's stuff now, and wondering where I should devote my development efforts - to improving his stuff or to improving uc_stock? It's a tough call... I don't see us personally expanding any more than what's there for core. It's lightweight and meant to serve as a foundation for contrib modules. CpILL's inventory has come a long way, and I haven't been able to keep up with it honestly. So really, I don't know and will leave that up to the individual developer. In the long run, you can count on uc_stock being in core and getting updated with Ubercart. I know CpILL is looking to edge himself out of that module's development, so maybe the next step would be for it to tie into the uc_stock API.   I've been meaning to start a post regarding the new uc_stock module, but I've been caught up in other coding. To elaborate further on Ryan's comments, the idea of uc_stock is to provide a general purpose stock utility rather than a catch inventory management system (there's just too many different business models to accommodate a catch-all solution). Starting this, I've added two basic functions: uc_stock_level These will add for basic adjustments and looking up of stock levels. I guess we'll see what needed feature will come along in the future (workflow-ng integration perhaps?). Ryan said: I think my next step is to figure out uc_stock so I have a better idea of how the two can play nice together. That's probably the best way forward, then. uc_stock.module is very basic in purpose and hopefully easy to build on. We won't be duplicating any efforts to build on the foundation ourselves, but we'll happily recommend a module that extends the inventory functionality when people ask for it. Yes, I'm working on that now. Since uc_stock is core, and has some features that the contributed uc_stocklevels doesn't, it makes enormous sense to me to build extra functionality around the core module. However, the architecture and philosophy of uc_inventory_api conflicts with uc_stock, so I am having to refactor everything. I plan to push out one update to uc_inventory_api with a bunch of fixes I've already made. In this push I will have changed the uc_stocklevels tables to agree with the uc_stock tables (with the appropriate update() function of course) - that gives you a simple and easy path to switch from the old uc_inventory_api to my new and improved one based on uc_stock without having to rebuild your tables. After that update takes place, I will be releasing another version where uc_stocklevels is done away with entirely.  OK - thanks for your answer. This means that if I don't experience an easy shift - I must be very unlucky. Thanks so much for the time and knowledge you spend in that. Alexandre   This module allows the use of uc_stock as an inventory manager  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
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: 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 The Solution 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 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.
  So the question now is, which module should have control of the uc_product_adjustments table? uc_product or uc_attribute? When it was created, uc_attribute was an optional module that provided features to its dependency uc_product. I don't think the idea of attributes and options should be required for someone wanting to sell products online. But if uc_product_adjustments belonged to the uc_product module, I don't think that uc_attribute should necessarily have exclusive rights to the combination column. But trying to accommodate any number of other modules could make it more complicated than it should be. Or maybe I'm just overcomplicating things unnecessarily. My suggestion is to abstract several of the columns in the uc_product table into another table that will allow for a one-to-many relationship. You don't need to have options, but it's there when you do need options. For example uc_products uc_product_adjustments The combination field would store the attributes (if there are none, then you can just store an empty array). The model field could be forced to be unique so duplicates would not be allowed in the system. Now to get the cost of a product with or without attributes "Select nid,combination,cost from uc_pruduct_adjustments where nid = %d"... if there are no attributes you get one cost, if there are attributes you get several. The summary of what I am suggesting is that in it's current state, the uc_product table isn't set up to handle attributes very gracefully. Here is one way to illustrate. Now on another product go to the Edit > Product , change the sku to 555. Now when you go to the Stock stub and change the Stock of SKU 555, it will change on both products. Changes need to be made to the uc_product table to allow for better attribute support.   Chirst! Nether of you really grasped the problem, which is the "adjustments" table in the first place: using serialised array strings as primary keys?!?? how many times were you droppped on your head when you were young? Read an data modelling book! Look up Database normalization!! (http://en.wikipedia.org/wiki/Database_normalization). Its like to dumb and dumber... |
|
There is "Inventory API and Simple Stock Levels" on the below thread if interested.
http://www.ubercart.org/contrib/132
Jim