Voting starts in March for the Drupal Association Board election.
Are there any plans to have this Module convert over to a transaction system? As mentioned on the following links:
Thanks for the pointer.
The reality is that I don't have any grandiose plans for this module. I found it in the issue queue and turned it into a module :-)
If anyone has significant plans and wants to work on it, I'm *very* willing to work with them.
I think we need a few things to accomplish our goal here.
* Stock changes should be tracked.
* Hooks should be called for stock changes.
We need a feature list. So folks, what's the feature list?
I think Commerce Stock should be extended to support both "Transactions" and "Bin Locations". Stock is more than just a Sum of available inventory.
In a perfect world physical stock would be stored in one physical location, but in real-life, stock is spread over multiple locations. An example would be having a quantity of Shirts on the show floor, a larger quantity of shirts in supply, and an even larger supply in the warehouse. Even then, the warehouse employees may have split the stock in the warehouse into multiple locations.
I see a few different use cases:
A product should start with a single, DEFAULT, location. There should be a way for a site maintainer to create additional locations, or Bins, that the product stock is allocated. And, a way for that stock to be transferred between locations and that transaction stored.
Transactions should work like your bank accounts.
That's a good list. The point about stock being in multiple locations is a good one. Our warehouse keeps a decent quantity of items in their production area space in order to speed up the packaging process. So, the available quantity includes both the stuff on the warehouse shelves, as well as the quantity sitting on the production floor.
We also ship large amounts of items to events for distribution. Whatever is not sold at the event comes back into the warehouse. So you might also want to have some way to deal with stock returns, so that when a customer returns an item it can go back into inventory.
I'm a little unclear whether travelertt is referring to a bin and storage location as the same thing. Assuming yes, I would extend travelertt's list to include storage location in addition to bin, with storage location being the higher level entity. One storage location can have multiple bins. I also agree with travelertt that inventory management needs to be transactional. I would add that a robust inventory management solution is, in my opinion, a critical function for a commerce system.
For what it worth, here is my work concerning a module for stock management.
It is a transactional stock management in the way that it uses "stock entries" (a specific entity) to store the different stock input / output.
The sum of the stock entries for a product is then calculated and stored in a "stock field" (a specific stock field, i wanted to create a widget to make it more user friendly on the front end rather than having stock = 0, having "out fo stock" for instance).
It consists of 2 modules:
- Stock : contains the "stock field type", hooks on the stock entries module, and functions to calculate the current stock value for a specific stock field. I decided to use a stock value at the stock field level so that you can use multiple stock values for the same product (multiple warehouse for instance).
- Stock entries : contains the "stock entry" entity type (Product sku, quantity, stock field name reference, order number reference for info, note text field in case it is a manual stock entry creation) and a STATUS. STATUS is either "ACTive, INACTive, ARCHived" : When a stock entry is created it is active, once the system will have calculated the stock taking into account this stock entry, it's switched to ARCH. If an order is cancel for instance, the stock entry is passed to INACTive.
I stopped working on it because i had other priorities to handle, but feel free to use it... I remember i was blocked because of the Rules workflow. I wanted to use RULES to automatically create a stock entry when an order is passed to a specific state, it makes the module very flexible for any time of business including site that would have more than the default order states. But it also requires to CANCEL a stock entry when a line item from an order is passed to Cancel state for instance. The code itself seems to be almost fine (the rights and access have to be checked, and it may have some inconsistencies in the calculation... it needs testing) but you need to set up several Rules
Let me know if anybody is willing to work on it with me. rfay are you working in commerce guys us office or french offices ? If anybody from the French office is willing to work on it, i can stop by anytime (i've already been there for interviews)
I'm very tired right now so sorry if im not very "precise" concerning my module....Be gentle on the code quality, this is my first module ever :-)
I also forgot to say:
The stock module also have a "initialization" function to recalculate the stock of a product based on all the stock entries concerning a specific SKU.
You're probably better to create a sandbox with your module, rather than posting it here. You could post a link to it here :-)
BTW: I'm open to somebody else taking ownership of this module, as I don't actually use it. I took it over because it was just a tarball in the queue and I thought we needed it.
So if you have vision for Commerce Stock and time to spend on it, let me know.
Sunflowers11, yes "Bin Location" and "storage location" are the same thing. Sorry if I caused any confusion with regards to that. Storage location is just a more generic term. Used more often where "Bin location" would be less appropriate. Bin Location comes from the terminology where product is actually stored in "Bins", actual bins, totes, or buckets. Those Bins are often given a name or location like A25 where A is the shelf and 25 is the position on the shelf.
I do like your idea where the Locations could have some hierarchy. Like in a scenario where you have your main warehouse and a Over-flow warehouse. A Product has 2 locations in the Main Warehouse (A25 and G56), and 1 location in the over-flow (Z45).
One thing to remember is that "Storage Locations" are independent of products. One day a product Shirt01 could be located at Location A25, but the next day that location is filled with Jacket05, and again on the third day that location is empty and has no product.
Locations don't move around, they are a fixed location.
Hope this clears somethings up.
Unfortunately I am not really a Drupal dev and I cannot spend to much time on this module as this is just a small part of my project which i'm planning to launch by September 2011. Never created any sandbox but i'll check it out as soon as i'll have time ! If anybody wants to use my work let me know ! :-)
Project in sandbox here for those interested in my work : http://drupal.org/sandbox/liupascal/1186926
I removed statuses on the stock entries because it was making the workflow too complicated.
Basically the system works as follow :
1/ Add a stock field to your product
2/ Create a stock entry for a specific SKU and field with a quantity
3/ A hook is "linking" the 2 modules (stock entries and stock) to automatically update the quantity of stock remaining for a product. Typically, you create a stock entry with positive value when you receive goods, and create a stock entry with negative value when a product is sold. Hooks will be automatically triggered to reflect the stock variation of the product.
4/ You can set up rules to automatically create the stock entry based on the workflow you want (typically, order states)
I create the following rules :
a) create stock entry on order update (check the order status to see if the stock should be decremented at this stage, and loop over all the line items of the order)
b) delete stock entry on order update (check the order status to see if the stock should be impacted it this stage, say the order has been cancelled or is back to cart status, you probably don't want your stock to be decremented)
c) delete stock entry on order delete
I hope it can help someone ! I'm bad a everything that has to see with 'front end' development, so if anyone wants to dig in and come up with nice widget for the stock display, let me know...
Marked #1209474: Transactional stock as a duplicate of this one, where the author points to @liupascal's sandboxDC Transactional stock
I created Commerce_stock Roadmap that will attempt to resolve this issue in a version 2 of the module
Transactional stock feature here : http://drupal.org/sandbox/liupascal/1360184
Read [#1269168#comment-5320858] for more info.
Maybe this feature can close this issue, as the "real" transactional stock implementation will happen in v2.
Posted by liupascal on December 3, 2011 at 6:03pm
Here is a feature i've built for Commerce stock v1. It uses rules and a custom content type that acts as a
It doesn't fit any "multiple location stock" but it's a start for using a transaction system. I took quite a bit of time to figure out how to synchronize the order / line item activities with the transaction creation, but now it works.
Some rules are not as optimized as they could be, but it's sometime need to work with the current state of Rules and Commerce behavior (as much as I could, i used existing rules actions / conditions).
I definitely think the rules defined by this feature can be adapted for commerce stock v2 to fit with a custom "Stock entry entity" (which would then open a door to multiple location stock i think). I used stock content type cause I'm lazy and wanted to focus on the synchronization rather than struggling with entities.
Some notes about how the features was designed :
1/ I didn't directly use a line_item reference field in the stock entry content type, because Commerce controller wipes out all the referenced value when a line item is deleted -> since I only had a "After deleting a line item" event, i couldn't fetch the stock entries being related to the line item deleted. (I had a few headaches before figuring out)
2/ I had to implement a "Data convert" action (follow #1301022: Add a type conversion action) as Rules currently doesn't implement it. And since Commerce line item quantities is defined as "decimal" it was required to match the stock field type (btw, i do think we should handle stocks as integer, like commerce is doing with the prices :-) )
3/ Manipulating data that empty values data with Rules is a real pain in the ass :-) I had to create extra rules component to handle the case where a commerce_stock field is empty (and not equal to 0...)
Anyway, here's the feature : http://drupal.org/sandbox/liupascal/1360184
looks like the correct approach, My plan for commerce_stock v2 was to
1) have a rules driven approach
2) the module will include the core functionality of controlling stock using events and actions and use sub modules to implement the business logic.
The "commerce transactional stock feature" is a perfect fit as it is also rules based and does not need to directly interact with commerce_stock, the two can work together without stock needing to now about it.
I think this can become as an optional module included with stock or as a related project, would be good to remove the reliance on features so it is a proper module.
It would be good to go over together at some point so i can understand better how the rules work.
Just wondering if this has progressed at all with the release of Stock V2? Can this Sandbox module be used with V2 or is a rewrite needed?
no v2 is not currently supported, just posted http://drupal.org/node/1530136.
it is possible that the current version works with 2, if you get a chance try it out and let us know
We've managed to create a transactional stock system using Relation module and Rules, along with Stock. The implemented example was a stock per store model.
We created a "stock"-relation type that would relate one store to one product. This relation type would have an integer field which would store the stock of that specific product in that specific store.
We then used rules to create a stock-relation for all products when a store was created or for all stores when a product was created. VBO was used to load the entity list for each loop used above.
The other rule was used to update a product stock whenever any stock relation was updated. Again VBO was used to load the stock values filtered by the current product and Rules did a simple math of summing all the values up and updating the product stock value.
Hook me up if you need more info on this.
@mariomc sounds cool would love to find out more. got a couple of mad weeks lined up but will try and get in touch once free.
Thanks again this is a hot issue and its great to see people coming up with working solutions.
We would like to introduce our recent work: commerce_stock_record:http://drupal.org/sandbox/jimmyko/1651594
It is a fieldable stock entity type that could be configured for different stock user cases. The implementation comes with a sub-module for tracking the stock transactions. It is designed to work with commerce_stock v2.x (with rules) and views.
By the way, the sandbox module is under heavy development and it is in a very early stage and in experimental quality.
Your feedback on it is highly appreciated.
@quintux looks cool, i love the idea of a stock record can be used in varies use cases, will check it out.
I've been testing the solution posted in #22 by @quintux. It is quite significant and so far I haven't found a single bug with the latest checkout of commerce_stock-7.x-2.x-dev. It deserves a serious look.
By adding a "Location" selectbox field to the Commerce Stock entity, I can model 2 warehouses - one in each of the two countries my multicurrency commerce site serves.
I'm now digging into see how the stock transactions work, and if this module will go all the way to meet my needs. I'll report back any more important information.
Whatever the final result, thanks for the great work @quintux!
@quintux, re #22
Haven't tested it yet but looking through the code it looks great.
It is similar to what i am planning fro the next major version of stock (some time away), the main difference is that I am planning to add two additional fields:
The idea is to make those configurable for different use cases.
When i get closer to working on it, I will spend longer looking at your module.
For what it's worth the Vote API http://drupal.org/project/votingapi is a great tool to use for recording transactions that adjust a total. I've started building a system that uses votingapi to track the stock value. I store the order line_item_id to the vote_source. So far it is just a proof of concept. I'll post more if I make progress.
Greetings! 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.
Perhaps it makes sense for the stock module to take a similar approach for "Location" definition that Commerce Pickup does. In other words: leave it up to the site builder to create a Location entity/node/whatever, and configure Stock+Pickup to use it.
Hi. Please is anyone using commerce_stock_record mentioned in #22? Did you have to add a rule to ensure product's stock gets updated once a transaction is added? I could not find this, hence my question. Thanks
Drupal is a registered trademark of Dries Buytaert.