Progress update

version 2 now uses rules for all validations of stock this is done by providing rules events for triggering the checks and customisable actions for controlling the out of stock behavior.

Things to do for full version 2 release:
[x] Display stock availability as message
[x] Create a Stock Rules admin screen
[ ] Improved rule set for full release

Version 2.1
[ ] Add stock control to admin screen
[ ] Views / VBO integration
[ ] Control products appearance using rules

Other popular issues (maybe for version 2.2)
Increase stock when order is canceled
Backorder / Waitlist Capabilities #17 looks like a good approach.

UX improvement: allow showing first product variation that is in stock

Comments

Issue tags:-relation

The following are a list of related issues

Product bundles

Stock Issue 1220360: Product bundles and stock management of the individual items
Stock Issue 1288958: A working implementation of stock management for product bundles

Rules integration and validation architecture

Stock Issue 1290914: User encounters cart validation errors if the stock level is reduced below cart quantity
Stock Issue 1290842: Add To Cart validation does not take current Cart quantity into account

Transactional inventory

Stock Issue 1166600: Design transactional inventory system with transaction update hooks
Stock Issue 1269168: Generalized cart - the Bucket
drupalcommerce.org: A new stock control & multi location system
Stock Issue 1734468: Overselling & Transactional reservation system

Stock Issue 1166600: Multi Location Stock

Out of stock handling

Stock Issue 1403054: Backorder / Waitlist Capabilities may need something like Alternative line item basket
Stock Issue 1786054: Notes from our Sep 2012 session in Brighton
sandbox module: Commerce Waitlist

Stock Issue 1689458: Hide out of stock products on add to cart drop down - see http://drupal.org/node/1689458#comment-6619434

Issue 1689458

Other

Stock Issue 1142968: Is there any reason not to have decimal inventory? - Implemented

Stock Issue 1872932: Multiple stock price - beyond the goals of the module at the moment

Issue summary:View changes

update

Issue summary:View changes

updated as was old

Issue summary:View changes

Updated issue summary.

also liupascal's sandbox: DC Transactional stock

subscribe

Also RSpliet's sandbox: Commerce Product limit can be handled as a sub module

Ability to set Stock Threshold: http://drupal.org/node/1272648

Hello

Regarding the transactional stock system, I was thinking about "branching" off the "transaction" feature of my module - it would make a generic transaction entry module (store transaction for entity_type, entity_id, field_name, value) which could be used with rules to affect numerical fields values.
Since it is now possible to play with fields and entities in D7, i think many modules are using the "transaction" approach which is (IMO) way more user friendly to track

Then, a transaction would be fieldable, so that users could create a taxonomy reference field, with a vocabulary for stock locations (as taxonomy are fieldable as well)
We would end up with each transaction having:
Entity_type (probably commerce product), entity_id, field_name, location (taxonomy) value.
This provides enough information to handle site BY LOCATION ([#1166600#comment-4541374])

Then a simple rule acting on "Transaction was created", checking the type of entity, can update a target field value (probably the stock field).

Let me know if this approach looks interesting to you to handle the transaction issue

@ liupascal
I tried to use Taxonomy of locations as it is very elegant and clear idea. Problem is, however, that taxonomy terms are displayed to the public, together with its RSS. It seems to disclose too much. I don't know how to avoid this display. OK, I'm not a coder, and expect there is some simple solution I don't know.

For transaction, of course, there should be dedicated entity type. I tried the fields:
- from (location)
- to (location)
- what (product or other resource)
- quantity/value
Together with standard data, as the author of transaction, date and ID, it makes complete set ("record") of data required for documentation of the transaction.

And Yes, the trigger ""Transaction was created" for Rules action is indispensable.

Of course, if You plan to make separate branch of Your module, I would suggest to untie the transaction from the commerce events (order update) in order to generalize transaction.

Another problem is how to handle real transaction consisting of many of above "records". Therefore I thought of the cart-like application.

@liupascal, @AndrzejG
As far as a vocabulary I don’t think this should be an issue as far as the public go. The vocabulary can be used for back end management.
I am not sure what’s the advantage of having a taxonomy and not a node or a custom content type, I suppose its simpler as doesn’t need contrib. modules for relations.

@liupascal, @AndrzejG
The plan is to have an abstracted check for “is item in stock” to be implemented by sub modules this is likely to be handled using rules. The way I see the event cycle is as follows (‘Stock’ are events added by the stock module)

1) Stock: Can item be purchased? (Used to enable disable an the add to cart)

2) Stock: is quantity available? (validates the add to cart user action and quentity update)

3) Completing the checkout process: reserve stock

4) transactional stock: Transaction was created

So the transactional system can implement those three events.
1 & 2: implement stock check (if requiered)
3: Create the transaction entity
Optionally you can also use “After adding a product to the basket” &
“After removing a product from the basket” to create/update the transaction entity and implement some clean up code for abandoned orders/

The implementation of the checks and the creation of the transaction will be down to the “transactional stock” sub module and can be as simple or complex as need to be.
The storing of the stock value can be held locally as it is at the moment or remotely again down to the sub module to implement.

If you only wont the “transactional stock” to record transactions you will be able to integrate it with the “simple stock” sub module where:
1 & 2 are handled by “simple stock” (as normal)
3: handled by “transactional stock”
4: “simple stock” decrement
not sure if 4 is needed at this point as both can happen on 3.

The questions for the stock modules are:

Does this event module work for what you have in mind?

The stock module will provide the product and quantity, does it need to be aware of the transaction entity?

@guy_schneerson

Yes, this is how i was seeing the implementation of transaction entries and stock module. Everything will be handled by rules to bring flexibility to the stock management workflow. (you create a transaction entry whenever you want in the order process, whether the order is still pending, or completed or else..., and you also decrement the stock value by creating a transaction entry, say when an order status is changed from completed to cancelled)

The stock module will provide the product and quantity, does it need to be aware of the transaction entity?
No, I think it should be different things. The stock module should be able to work "standalone", as this might be enough for some sites. The transaction entry module will simply be used as a "tracker" and will allow to easily implement a stock management "work flow" : it will use rules to modify the stock field value, just like it is done right now - except that with the transaction entry module, you'll be able to "track" the changes and refer to order that triggered the change for instance.
Then, by smartly using the field concept, and extending the transaction entity, you should be able to manage multi location stock

@AndrzejG

Rather than having a specific entity type, it will be a "generic" transaction entry that you'll be able to "specialize" (create a bundle) for your stock management - i think it will be cleaner this way, as the transaction entry module could be used in many other cases, and behave exactly the same.
For instance, to move a stock from a warehouse to another one, you might have to do the following :
Transaction #1 : Decrease 6 stock for product P1 from warehouse W1, related to transaction T2, reason "stock transfer to W2"
Transaction #2 : Increase 6 stock for product P1 from warehouse W2, related to transaction T1, reason "stock transfer from W1"
Or
Transaction #1 : entity type = Commerce product, entity id = P1, warehouse_node_reference = W1, value = -6, related_entity = T2, note = "stock transfer to W2"
Transaction #2 : entity type = Commerce product, entity id = P1, warehouse_node_reference = W2, value = +6, related_entity = T1, note = "stock transfer from W1"

Ad #9:
In fact, it doesn't matter if the location is implemented using taxonomy or node or other (custom etc.) entity. I tried this for 2 reasons:
- it seemed to me that "modeling" enterprise as a set of locations could be more obvious or "elegant" when implemented as the terms; maybe it is not a case, of course.
- during the crisis of token module the taxonomy token was announced by DaveReid as the only working implementation of relations tokenization; of course it was valid for particular moment.

So, this is irrelevant now, and You can ignore this idea. It is my point of view, I don;t know standpoint of liupascal.

Ad #10 and #11

'1. In #9 I focused only on the transaction entity, not the Rules reacting in decrementing and incrementing corresponding stock; sorry for not complete answer.

'2. I opt for #11 approach, as I understand the intent to make transaction entity acting as an extra add-on, used only when required, and not disturbing e-commerce tasks. My trials were also going in line with this assumption.

'3. I know that easier is to decouple transaction into two: T1 decrementing W1 stock, and T2 incrementing W2 stock. However, I tried to respond to my customer's suggestion, and trigger both Rules reactions using one transaction "ticket". He is the manager of middle-size service station where they have Main warehouse and several on-hand stocks beside the workstations of servicemen. He suggested that making two transactions for one movement of a set of parts could be confusing for stock operator and possibly causing errors.
Therefore my plan was as follows:

- Initiate new transaction ticket, by filling only "from" and "to" fields (reference to locations) (ticket is an instance of transaction entity)

- Once transaction is initiated, the stock in "from" location is displayed (for example as a View Reference attached to the transaction ticket or - much better - as a View block in the sidebar). This View contains SKUs, and stock value and link "add to the Bucket" for each SKU at least.

- Operator adds to the Bucket parts chosen and inputs the quantity of items for each chosen part (same as adding to the cart in e-commerce)

- After checking and eventually editing Bucket content, operator fires transaction.

Rules response is: decrementing W1 stock; incrementing W2; and generating documentation of the transaction, enumerating SKUs and transaction quantities of these SKUs. This documentation should be referenced (or attached to) transaction ticket.

As far as I understand, #11 idea is more flexible, and using transaction entity as a bundle I could build also other workflows and documentation options. Is that so?

Now I think about simpler solution.
Stock operator goes to the View (page or block) of W1 stock.
Operator fills the "from" and "to" fields IN THE BUCKET
Operator adds parts and fill-in the quantities
Operator fires the Bucket
Rules decrement W1, increment W2 and generates the documentation.

BTW: Obviously, I tried to make Rules generating documentation card for each SKU separately, and using Views to display all the transaction. However, such option is OK for relatively small companies, because system would generate huge quantities of documentation cards.

Sorry about the mess.... my brain just exploded...

Here are a couple of other related concepts...

BTW, I've seen the transactional inventory thread. I just haven't seen this all coming together in quite this way.

Here's a rough idea of what I'd like to see in a basic (standard) transaction log:

(sorry, I know this is ugly and the timestamps are bogus)

ID; SKU; timestamp; operation; qty; state; source; destination; means; notes
234445; 2524; 1256953732; add; 500; fresh; ?; jar 17; manual entry by uid:26;
234446; 2524; 1256953732; add; 400; fresh; ?; jar 24; manual entry by uid:26;
234447; 2524; 1252955726; subtract; 305.7; sold; jar 17; customer #823; sold on line item 8237;
234448; 2524; 1252955726; subtract; 1.2; removed; jar 17; spillage; manual entry by uid:12;
234449; 2524; 1252947746; subtract; 4.2; removed; jar 24; testing; manual entry by uid:18; annual quality control for purity certification
234450; 2524; 1253566788; subtract; 0.2; removed; jar 17; evaporation; evaporation; (a factor like this could be applied periodically based on the current quantity)
234451; 2524; 1258684424; subtract; 0.3; removed; jar 24; evaporation; evaporation;
234452; 2524; 1258973424; change; 30.5; moved; jar 17; jar 24; manual entry by uid:26;
234454; 2524; 1358923524; change; 426.2; aged; jar 24; jar 24; automatic entry; (probably a good time to start discounting this stuff)
234455; 2524; 1558958394; change; 162.4; rancid; jar 17; jar 17; automatic time-based entry;
234456; 2524; 1558975644; change; 426.2; rancid; jar 24; jar 24; automatic time-based entry;
234457; 2524; 1558953324; subtract; 162.4; removed; jar 17; waste; manual entry by uid:26; (yuck!)
234458; 2524; 1558958833; subtract; 426.2; removed; jar 24; waste; manual entry by uid:26; (yuck!)
411123; 5534; 1358955224; add; 100; available; ?; bin 8; manual entry by uid:27;
411124; 5534; 1252947740; add; 50; available; ?; bin 5; manual entry by uid:27;
411125; 5534; 1252965115; change; 3; moved; bin 8; shelf 27; manual entry by uid:21; to feature in front window
411131; 5534; 1252951010; change; 35; reserved; ; customer #823; reserved on line item 3746;
411132; 5534; 1252956622; subtract; 35; sold; bin 8; customer #823; sold on line item 3746;
411127; 5534; 1252965115; change; 3; reserved; bin 8; front desk; manual entry by uid:33; holding for customer pickup
411129; 5534; 1252956622; subtract; 3; sold; front desk; customer #5234; sold on line item 3555;
411133; 5534; 1252965115; change; 5; on loan; bin 8; on loan to sales rep uid:6; manual entry by uid:6; loaned to sales rep
411134; 5534; 1252965115; change; 3; on loan; bin 8; on loan; manual entry by uid:26; loaned to distributer
411131; 5534; 1252959199; change; 22; reserved; stock; customer #645; reserved on line item 3994;
411135; 5534; 1252955726; subtract; 2; removed; bin 3; repair; manual entry by uid:4; pulled out of stock for repair
411136; 5534; 1252815721; change; 2; moved; shelf 27; bin 5; manual entry by uid:21; returned from display
411129; 5534; 1252956622; subtract; 4; sold; bin 8; customer #634; sold on line item 4526;
411137; 5534; 1252955026; change; 15; damaged; bin 5; bin 5; manual entry by uid:11; still functional but found cosmetic defects
411138; 5534; 1252955720; change; 15; damaged; bin 5; bin 3; manual entry by uid:11; damaged items put aside
411139; 5534; 1252965115; add; 3; added; on loan; bin 3; manual entry by uid:21; returned from distributor
411140; 5534; 1252953723; add; 1; returned; repair; bin 3; manual entry by uid:4; returned from repair
411141; 5534; 1558958494; subtract; 24; removed; bin 8; -; theft;

So with this, in addition to all of the regular sales data we get from Commerce, we also know 588.6 out of 900 units of SKU 5534 became rancid and went to waste, and for SKU 5534 we know:

We started with 150
1 is on display on shelf 27
1 is out for repair
5 are out with sales rep uid:6
51 sellable items are in bin 8
37 sellable items are in bin 5
3 sellable items are in bin 3
15 slightly damaged items are in bin 3
22 are reserved for cid:645
76 are available for sale
22 were stolen

...good to know.

AND, we have a record of when all of the changes took place.

To some degree I think this is just a conceptual difference in perspective from the current discussion. Instead of focusing on the process of having "transactions" change the state of the inventory and then maybe keeping a log of those changes, focus instead on the idea of the log/history of transactions. (Of course the transactions still need to happen.) Make the log/history of transactions for each SKU a robust part of the system so that we can use all of that data more actively to build a comprehensive, accurate and detailed picture of the inventory on an ongoing basic and build valuable reports that can incorporate lots of other important inventory-related business concepts like tracking theft, repairs, loaners, damaged items, and other things across the entire database and over time.

Hi @videographics the idea behind @liupascal proposal (#11) is that the transaction entity can be specialized by creating a bundle this will alow you to add any additional fields you require. it is then up to you how you implement transactions: rules, bin management interfaces with custom code, views reporting ...

All the stock module needs to know is can i sell this? and how many can i sell?.

we may add some additional state information at some point for things like "on order" but i am not sure at this point how that would fit in.

Thx Guy. I'm certainly in favor of using the transaction entity model and rules to accomplish all of this.

I fully admit I may be off on a little bit of a tangent with my last post (edited to make it slightly less silly) from the details of the current discussion. The point my post was throw out a number of related concepts to reconsider at this point. Here's what it comes down to:

• I wanted to put out a rough "picture" of what a list of inventory transactions might look like to get people to visualize various applications of this. And, I also wanted to help people visualize the "end result" by showing what a detailed status report of the inventory for a couple of products might look like.

• I wanted to remind people that we might be dealing with fractional inventory.

• I wanted to highlight the importance of dealing with "reserved", "damaged", or "on loan" stock that may or may not be considered "available" depending on the use case. (My sense is that there may be some value in standardizing the way conditionally available products are implemented.)

• I wanted to highlight the value of maintaining a reliable and complete history of all of the inventory transactions so we can perform detailed "audits" of the system and report on this data going back in time. I want to be able to look at the "current" inventory numbers and the "inventory transaction history" and have them match -- regardless of which inventory modules are being used.

For these things in particular I'm concerned about the potential conflicts that arise from having inconsistent support for these concepts among the different inventory related modules.

The "style" of my log entries relate to the discussion in #13 about splitting a "move" into two transactions. I was trying to show a model that handles it all in a single transaction that uses positive, negative, and static entries. It uses positive and negative entries to show increasing and decreasing availability of product, but also static (change) entries to accommodate inventory moving about a storage facility, being only tentatively available (reserved, on loan, slightly damaged, old), and changing in various ways through damage, spoilage, etc.

i'd like something like #17 is getting at

Wow, videographics, I dreamed about something like that (#17), but simply was afraid... ;-)

On simplification: the state and the destination can be contracted to one: destination, as they are logically equivalent. You can have "jar 17 fresh" and "jar 17 aged", "jar 20 to repair", "shelf damaged" and "shelf to assembly", "department", "customer" etc. These generalized destinations model the architecture of business, of course.
Moreover, You can make some simulations of calculations, for example expenses of product, if using "pseudo transaction" (not changing stock quantities). For such task, apart of materials you can "move" working hours to the "calculation" (destination). You can plan production, monitor resources consumption etc. Huge lots of applications!!!

My original idea was even simpler, based on the basic logistic standard of storage, which consists of 3 variables only:
what
where
how much.
System has to "know" only these 3 data at given moment (time).
So, my stock cards (documentation cards) contain only these 3. (BTW it appeared too much to me as non-coder ;-)

I planned to include all "movement" data into the transaction entity, and reports based on Views.
Of course, particular transaction (document) can provide any useful set of data, incl. operator/clerk name, timestamp, notes etc.

I have to correct last sentence of #14. It is not true, even standard Drupal installation with MySQL could handle all. Why? Because transaction only Updates stocks, i. e. documentation cards (stock card for particular item at particular location) is only once generated, and then updated by transactions. So, for 3000 SKUs (automobile factory) and - say - 50 destinations that make maximum 150 000 stock cards. MySQL can handle 10 times more records.

In fact, I had no problems with building stock cards (what, where, how much) nor with transaction cards (from, to, what, how much), as we can use Taxonomy, Nodes, or new generic entities as Fields Collections or Models. Problem is with Rules. I tried both in Drupal 6 and Drupal 7.

- Rules are not able to generate anything but system message when looping. Such action is blocked in order to avoid recursion even if limit loop count is set. Strange for me.

- It seems that Rules are not able to search for entities, say Node, having particular values in two fields (or select data twice, first pass looking for first field value, and second for second field within the set selected in the first pass).

These two disadvantages pushed me to ask e-commerce coders for Bucket application.

OK, I found a solution.
Seems to be complete. Need some time to test and make a demo.

I think it might make sense to look at using the budding Relation Module (http://drupal.org/project/relation), which already has an API for defining relationships between entities, as a standard way of describing the relationships between inventory and the locations where that inventory might be stored? Also, because the Relations Module uses entities to define relationships between other entities, it's fieldable so it is able to describe the relationship in any way the user might want. So this could be used to store a log of any type of information including when, why and by whom a certain amount of inventory was added, moved, or removed.

Probably Yes, You are right, vidoegraphics. However, there is caching problem and in practice module is useless for this moment. Maybe in future it will be great. (I tested it some weeks ago, so it is time to come back.)
I found 2 ways to avoid creation within the loop, and now have similar problem - modules are not working properly or raise errors.

So, general low quality of Drupal seems now to be the only obstacle hindering most simple solutions. Let's keep fighting ;)

Issue tags:+relation

I totally agree about Relation. It's got a ways to go. I just meant it looked like a promising approach to consider. (I actually have so many other real uses for it in addition to this. I hope it flies.)

Since we're still talking about a roadmap for Stock and looking into the future a bit, I just thought it should be included in the discussion. If it's the train we ultimately want to catch, we don't want to miss it and then be faced with trying to catch up with it later.

...still thinking. Here are my latest thoughts... Commerce Stock could be based on three new entities who's data is completely independent of any of the Drupal Commerce entities:

• One to handle the various locations and conditions the products might be in
• One to hold the current value for the amount of each SKU in each location AND whether or not it's available, unavailable, or reserved for various reasons.
• One to be the standard mechanism through which change changes to these values are made which will double as a way to report on the stock changes over time and allow for consistency checking

(It turns out, I ultimately can't really find a good use for the "Relation" module in any of this.)

PART 1 (Location/Condition)
First, we need an entity "Location/Condition" to describe the different places or condition a product might be in. Entries might be something like "existent", Bin 7, "being repaired", "Jar 72", "scratched", or they might be more complex like "jar 6, bin 27, shelf 2, aisle 9". Either way, the entities are fieldable so one could even choose to put a picture of each storage location, a map, taxonomy, or something much more complex if it was needed.

PART 2 (Stock State)
Then, we need another simple entity (let's call it Stock State) with fields like this:

SKU
amount
availability (available/unavailable/reserved/...)
location/condition (referencing the "Location/Condition" entity defined above)

The Commerce Stock module would have the ability to summarize the Stock State records for each SKU (many implementations would only have one record per SKU) to report on product availability and where the product is located. What's important here is that each SKU could have any number of these "Stock State" records depending on how many locations it might be stored in. But still, since we'll only have one entry for each SKU for each location, it should be pretty manageable and performant -- as opposed to trying to summarize the entire history of change records from a log.

PART 3 (Stock Change Manifest)
To accompany this, you'll have a transaction log entity to record each change to the Stock State. This looks like this:

ID
SKU
timestamp
operation (adding, subtracting, or changing, the stock)
amount
source location/condition
destination location/condition
means (who or what part of the system initiated the change)
notes

From this, you'll have a double-check on the availability data AND a complete audit trail for where everything is, how it got there, and when. Technically, this Stock Change Manifest could be done separate from the first two, but we're going to need a standard method for manipulating the Stock State anyway, so why not standardize on doing it this way from the get go?

This is an incomplete idea. I can see that issues related to availability changing and being recorded in the Manifest need to be tightened up.

Initially, I thought "location" might be best dealt with independent of "availability" -- and would be handled by a sub-module -- but this seems to work so I've changed my mind.

What if those Location/Conditions were blocks of time? Would we then have a way of managing the availability and the sales of time slots for various resources? If so, this could have value for a whole range of use cases... consultants, attorneys, hotel room reservations, equipment rentals, etc... without having to create a separate SKU for each block of time.

Ability stop "denying add to cart" and other forms

The rule integration should set a value in the action for the stock module to check this can be "Invalidate user action" and "invalidate message" and can be a custom action.
This will allow the UI to work as it does at the moment or be overridden like requested Is there a way to add instock quantity to the cart if the user tries to add more than instock quantity?

Hey guys,

Here is a feature i've built for Commerce stock v1. It uses rules and a custom content type that acts as a
transaction entry.

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: Action: type conversion for numbers, integers, and strings) 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

liupascal as far as 3/, all stock fields now default to 0

Issue summary:View changes

@guy_schneerson

I know :-) the default value is 0 but you think you can still put an empty value in it if you force it (enter an empty value and save), unless you set it as required in the field setting since it is now "opened".

Some people may want this value possible for workflow purpose (like 0 value means : "out of stock item, to be reorder to the supplier", while empty value could mean "out of stock but don't re-order") so I took this option into account.

Other than that what do you think of it ?

@liupascal, AFAIK another problem is that Rules condition "entity has field" returns FALSE if data is empty (not zero), and therefore U cannot use this field in subsequent Rules action. It does mean that empty value is recognized by Rules as no field at all.

So, I think U should try to invent some other way to signal "out of stock but don't re-order".
Why not to hide such item?

@AndrejG check at the rule feature you'll see a ruleset component that deals with the problem.
You can safely use entity has field, and check whether it's empty with "field is empty" (or something like that) rather than "data comparison"
On the other hand the "out of stock but don't reorder" is just an idea - i just wanted to leave this option for flexibility

best to move discussions on transactional stock to http://drupal.org/node/1166600 so they dont dominate or get lost.

Issue summary:View changes

update

Issue tags:+relation

updated the issue summary as it was old with new objectives for a full v2 version of the module

Things to do for full version 2 release:
[ ] Display stock availability as message
[ ] Add stock control to admin screen
[ ] Views / VBO integration
[ ] Improved rule set for full release

Other popular issues (maybe for version 2.1)
Increase stock when order is canceled
Backorder / Waitlist Capabilities

Issue summary:View changes

updated

Issue summary:View changes

Updated issue summary.

Feature freeze for V 2.0 only outstanding issue is Improved rule set for full release

Issue summary:View changes

update target for V2

Issue summary:View changes

new ux section

Issue summary:View changes

update

Issue summary:View changes

updated 2.1 tasks

opps removed wrong post

work on Improved rule set for full release has started input will be greatly appreciated.

Issue summary:View changes

added note to Backorder / Waitlist Capabilities

I have added to new admin sections
#1964538: Create a Stock Rules admin screen
#1998946: Add Stock control admin screen
what I really need is some feedback on #1744468: Improved messages and UI for Version 2 so we can get version 2.0 out.

Issue summary:View changes

update progress

Issue summary:View changes

updated