Discussions

A new stock control & multi location system.

Hi,

I don't know if this is the right place to bring this up, but its called brainstorming so i'll give it a go.

I would very much like to see a ubercart being multi location and have a better stock module. I have no idea how much of this is possible or even if it should happen, but I figure now is the time to throw the ideas out there.

I would be willing to put a reasonable sum up to bring at least multi-location into uc3/d7 when the time comes, I will need it.

Paul.

---

First - better stock control.

Every item (inc. attributes) should have at least a current stock, a threshold and a reorder level (how many to reorder). Each item should have a supplier attached which would hold contact details, order thresholds etc. Each item should have more than one SKU (e.g. barcode, BIN location, Supplier Ref, Manufactuer Ref). All this should be available from reporting so that you can run clever reports like "print a list of all stock items that need ordering, grouped by supplier, showing SKU, Supplier Ref & Reorder Quantity if supplier order value is over threshold" etc.

A simple way to add stock to the system is needed (e.g. a table of SKU, Quantity In, Cost Price fields).

Second - Multi-location

This would allow shops (like me) to have multiple real world locations using the same stock system and probably the new uberpos module combined would mean we can do away with other epos systems etc. Benefits could be intershop transfers, stock enquiries, customers choosing where to collect from etc. A dual method of independent ordering from supplier directly to each site and a overall ordering. This would allow some people to have a warehouse and retail shops ordering from that and some people to have each retail location order directly from the supplier themselves.

I propose that there be two options for web sales. Either one site is designated as the only web location and therefore only in-stock and active items from that location are shown, or that a selection (or all) sites are selected. The system would then show all items available to those sites and pick and choose which site to send what items from (e.g. if all items are available from one site, ship it from that site. If not, ship from as little quantity of sites as posssible) etc. This could also be used for adding drop ship items to your normally held in stock items.

paulg
Posted: Oct 25, 2009

Comments

Ryan Ryan Szrama on October 25, 2009

Hey Paul, for what it's worth, I think stock should be a necessary feature of any mature e-commerce system, and I'm happy to say that the new vision for products in Ubercart will make the development of a stock component a lot simpler. Once we know exactly what a product is and when that product is being sold, we can start tracking stock effectively. I'm not sure about the complexities of multi-location stock management being an essential feature, but at the very least there's no reason a more solid set of core APIs can't better enable someone to develop that.

harrisben on October 26, 2009

After reading Ryan's post (Fieldable Products and the Add to Cart Field) I'm not clear on eactly how attributes will work in the future so I'm hesitant to delve too much into their future handling, but I will say that it's important to remember different people are using attributes in ways that would conflict with the method you described. While I personally use attributes to denote unique SKU's, there are people who use them as variations on single SKU (ie, more in line with a Bill of Materials).

Also, multi-location is not overly complicated to implement but doing so also means that functionality needs to be included to manage the transfer between such locations.

Ryan Ryan Szrama on October 26, 2009

Yeah, we have this in mind even if that proposal isn't quite complete. Basically, when I think of attributes as they are now, there are those that function as product associations (i.e. attributes that are specifying unique SKUs - the size of shirt) and product describers (i.e. attributes that give the customer a chance to specify something unique about their purchase - the name on a plaque). The description in that post replaces the need for the first by letting you define your products up front and then join them together in a product display around those particular attributes. It doesn't adequately consider product describers, but that's just because we haven't got that far. It's definitely on the radar! : )

(Cross-posting this in that thread so this is clear.)

Damien Tournoud on October 28, 2009

I would like to add that products being first class objects, they are unambiguously identified. A product is something you have in your (physical or virtual) warehouse(s).

Once we have a unique key to identify a product, the attribute management and stock management become two separate issues, and it is easier to deal with them.

redben on October 31, 2009

The features you suggest are interesting for sure, but i think they fall out of an ecommerce solution scope. Manifacturer handling, POS...etc are "supplychain" related features Ubercore is meant to focus on core ecommerce features.
But may be ubercore could consider having API's that open the door to integration of such features !

chrisstrahl on November 12, 2009

Most of the time SCM functions like bins and reorder points are handled by a back end ERP system or accounting system with better inventory controls. That's not to say that we couldn't create a warehouse management system / SCM / ERP / accounting system out of Drupal, but having it be more than a stock integration starts to have it creep out of the bounds of ecommerce.

chrisstrahl on November 12, 2009

From a fulfillment perspective, multi-location is an important thing.

For example, I'm a company that ships chocolate (as one of my prospects reviewing Magento does). I have chocolate in my San Francisco warehouse, and I have it in a warehouse on the east coast (let's say New York). Because chocolate melts in the summer, and it's semi-perishable, I need to consider where I'm shipping from when making a stock decision. If I'm in St. Johns, Newfoundland, and I'm ordering some chocolate in the middle of July, the stock I'm getting should be from the NY location. Similarly, if I'm in Portland, OR, I'd want the chocolate to come from SF.

This has huge implications for integration. Other than very very basic back-end systems, almost all of the inventory and fulfillment tracking systems utilize multiple warehouse locations. Multi-location is also a tremendous selling point for more organizations when it comes to ecommerce and fulfillment. It also is supported by UPS/FedEx/etc for tracking and notification purposes.

IMO - this would be an awesome addition. It doesn't need to be much. Just a list of locations with separate inventory quantities for each item would be a big step in the right direction. Location utilization could be determined either by the customer upon registration or assigned by the client for each customer.

markalosey on April 9, 2010

I am in 100% agreement. We gave up multi-warehouse capabilities when we moved to ubercart. (not a big deal considering what we gained)

We have been missing it and it's important for us when showing in-stock/out of stock on the site. We are currently basing stock on the warehouse that ships the bulk of our orders. (problematic)

As Ubercart/Drupal Commerce becomes more accepted into larger operations like my own, there are more demands to get information from outside ...in, and have a flexible way to replicate/represent that data in the ecommerce system.

essbee on February 23, 2011

Just to throw my two cents in, I've used and constructed a few basic inventory systems over the years. I'm probably preaching to the converted but thought worth noting down.

I think the most important thing is that the inventory system be transactional. Paul highlights this at the end of his first point.

I've seen so many systems that simply use a single field that they just increase or decrease the value of. This is great, until the system needs an audit, or the figure is wrong. Then its pretty much not worth the bits it occupies.

A transactional system is basic but gives heaps more flexibility. Just a simple table of [SKU], [QUANTITY], [REASON_CODE], [DATE] [USER] is enough. From that the current quantity is just the sum of all grouped by SKU, it allows for both debits and credits (ie by using positive and negative numbers) of stock and gives full traceability to how the current stock level are arrived at.

Obviously the [REASON_CODE] would be admin configurable, just like order status to allow the full raft of purchase, return, wastage, stocktake etc etc.

</2c>

Zachary (not verified) on March 28, 2011

Transactional log of the changes to stock is very important for audits and reporting purposes. [SKU], [QUANTITY], [REASON_CODE], [DATE] [USER] sounds reasonable. Is anyone working on this in core or contrib?

travelertt on May 23, 2011

I want/need something like this as well.

I need a system that can keep track of stock in multiple locations, transfer products from one stock location to another, and report on the transaction history of that product.

If this system was in place then we can develop future modules that can deal with Cycle Counting, Auditing, Stock Purchasing, and other features found in commercial Inventory Systems.

I agree with essbee, I think transactional Stock module would expand future development.

m.stenta on February 4, 2013

Just wanted to chime in here... I recently started a new module that provides an "In-store pickup" shipping method+service: Commerce Pickup. It's very simple still, but it works by allowing you to select a specific entity type+bundle as your available pickup locations. These are then listed as options in checkout.

I could see it being very useful to integrate this with the stock module, such that stock can be managed independently at each location. So while the Commerce Pickup module may not be important to any of this, it would be great if they could work together.