Woocommerce: Manually Adding Completed Order Doesn't Reduce Stock

[ryanr14]

Had this through a ticket.

Initial stock: http://cld.wthms.co/N4Dy

Order manually added and completed: http://cld.wthms.co/bcAf

_EDIT_

Ahh, the stock doesn't change unless you select the product and choose reduce line stock. Is this the smartest way to handle it for now? Seems that a completed order, even if added manually, should reduce the stock by the qty set when adding the product to the order.

[roykho]

I think it should stay "manual" because what if store owner wants to add an order for a friend but don't really want to reduce the stock on the store front?

[ryanr14]

Sure, then their inventory just isn't correct. If they really had only 5 shirts and add a manual order for a friend (without reducing stock) whoever orders that 5th shirt online won't actually get a shirt.

[roykho]

Actually that was not the scenario I was referring to. I am saying sometimes they want to add order and NOT affect the stock publicly. So the way it is now, gives them a choice to either manually reduce stock or not. But if you make it automatic, then this wouldn't work.

[coenjacobs]

@ryanr14

Ahh, the stock doesn't change unless you select the product and choose reduce line stock. Is this the smartest way to handle it for now? Seems that a completed order, even if added manually, should reduce the stock by the qty set when adding the product to the order.

Yes, I think it is. Manual orders are manual in my opinion and should do little as possible automated, as store owners should be in control about these kind of things. If you have a better solution, I'm all ears, but I doubt it because there are always use cases where the new solution is less convenient (just as this one is probably not always the best, so we've added the option).

[ryanr14]

I think, after stewing it over, I've come to your guys side of the issue. :P

Just something we need to document since we're out of date here, and the issue was reported in a few accounts tickets (people emailing us since they haven't purchased anything). - http://docs.woothemes.com/document/managing-orders/#section-4

I'll file a doc report so Maria can delegate to me and/or track and get that section fixed!

[GitHubGreg]

Hi guys, interesting discussion. I personally am trying to use the backend for staff to enter regular orders, and would prefer they not have to remember each time to select all items, go to dropdown menu, choose reduce stock, click refresh.

Do you think there might be a way to automate this (perhaps as an option). If not, could anyone recommend the best approach to writing my own code to achieve this?

Thanks very much, keep up the great work.

[jlaurendi]

I think the way woocommerce currently handles this is very unintuitive. Adding an item to an order should reduce the stock. That's more in line with how the real world works. If I want to give a user a bonus item, it's coming from my inventory (where else would it come from..?). The inventory management system should keep of the track for me as much as possible.

splashingpixels, your question is "how can a store owner give an extra item but not reduce the stock count?". Add the item and then use the "increase line stock" option.

The cases where a manual order gets placed in our case is where the store manager wants to give someone a bonus or fix an order. I don't see why this shouldn't be automated. The case where the store owner has an extra item lying around not accounted for by the stock count seems niche to me.

[saturday]

I agree with @jlaurendi. In my opinion, this is definitely a scenario where you should opt-out of reducing stock rather than opting-in.

[rickad1234]

I am in agreement with jlaurendi. The system should reduce stock as manual orders are entered inventory is actually reduced. Additionally, I think when a manual order is placed and stock qty=0, Stock Status should update to Out of Stock or at least have you opt out of Woo doing this automatically. As a brick and mortar store, I use my website as inventory control so go in daily to manually reduce variations stock as items are sold in-store. My staff will have to remember to set stock status to out of stock almost every time as I carry only 1 of each item I sell. In Settings>Product>Inventory, it asks what qty should trigger out of stock but only works for traditional web orders.

[justinisamaker]

Just wanted to add another voice asking for @jlaurendi's suggestion to opt out of stock reduction. My client is in a very similar situation as @rickad1234 where they're using the site for inventory management, but still selling products through their storefront.

[timotheus-m]

I definitely support @jlaurendi's points. Also I explicitly disagree with @coenjacobs argumentation (sorry coen).
The current way WooCommerce handles the stock management on manual orders might be better for shops who do not actually track their inventory and have a lot of exceptions. E.g. I have a couple of t-shirts but I want to limit online sales to keep quantities available for offline sales or friends, but my actual stock is not reflected online. This scenario is in conflict with a bigger shop maintained by multiple employees who need accurate stock levels to avoid overselling and also track offline sales with WooCommerce.
I would argue in favour of optimisation for bigger stores in this case as it is never a problem to not track inventory, but it gets harder to accurately track it the more items and sales you have.

_tl;dr_ It's a non-issue if you don't want to accurately track stock and WooCommerce auto-reduces it on manually created orders, but it's extremely important if you need accurate stock levels.

@ryanr14 would it be possible to reopen this ticket, should I open a new one or is there a better place to continue this discussion? Thanks!

[kelderkold]

We really need to change this, back-end orders should not be manuelly, as a store owner i use this every day to make orders to my customers either because they don't have access to a pc, or because they just needed something extra.
why make this as a problem for us store owners, we are the ones that are using this feature and we need to it the easiest way.

next problem, why should i manually add the name and address with 2-3 clicks extra after i choose the buyer? that should happen automatically.

And why can I when selecting the products not add more than one ? this is also a extra work to after I added 20 product I must go back and click on each item, and increase the number.

This is really a hard work to make orders from the back-end
and it is not possible to do this from the front end and have the correct names on the orders.

[creativecollaborations]

We're in 100% agreeance with @jlaurendi points as well and @timotheus-m hit the nail on the head with his comments. Add us to the list of users who feel that stock management for manual orders needs to be revisited.

[THX2112]

I just got bitten by this. Entered phone orders manually and forgot to reduce the stock on some, then people were ordering online for stock that we don't have. Manual entry of sales should reduce stock automatically.

[jerryattric]

Is this actually on the horizon? Nobody gave a definitive answer. There is a need for this for some stores. I would love this to be a feature that could be turned on (off by default). Any news or updates?

[wmnf]

Yes, I agree that it should be opt-out of reducing stock versus opt-in when an order gets to procesing or completed. This is something we are having a hard time teaching numerous volunteers doing these manual entries.

[BlueValleyTech]

This definitely needs to be re-opened and handled more intuitively. The assumption when adding an order to the back-end is that it should function exactly like an order added by the front-end. If there really was a scenario where someone didn't want to deduct an item from inventory (I really can't imagine many real-world scenarios for this), then they should use the manual controls to over ride that.

Just tried to educate a client on how this currently works, and it is looking like the current functionality may be a deal breaker for Woo Commerce.

[bobbypureitrefurbished]

I really think this needs to be looked at. We're having problems with our stock when our staff forget to do this step when adding an order manually. I agree that the admin should have complete control over back-end ordering but I think the default functionality should cater for the norm and where necessary have a function to over ride this.

I have used other shopping carts and they've had a tick box (default ticked) to update stock when the order is processed. This can be unticked on the odd occasion you don't want to update the stock.

I also think the idea of updating stock on order complete (shipped) not order processed (paid) is wrong. We sometimes have 24 hours between when the order is paid and when it is shipping (complete) this allows a windows for customer to purchase stock which we don't have.

[woodydeck]

Anyone have a solution for this bug?

After reading the discussion I'm a bit miffed at how so many developers always seem to be out of touch with how their users actually use their creation. It's clearly the case that about 95%+ of use cases do not want it to function this way, and for the 5% that do, they should have the option to. There is not a right way or wrong way of doing it, but there is a clear condition it should be defaulted to.

Now the super majority of people are left looking for a workaround. In my use case I only create manual orders for items that have exactly one thing in stock. It's annoying, but not confusing. This is a disaster for people with variable quantities of products.

[mikejolley]

It's clearly the case that about 95%+ of use cases do not want it to function this way, and for the 5% that do, they should have the option to.

You have no data to back this claim up.

Manual orders are not that common. It makes sense to leave this to the admin control because if you automate it, a) they may miss this and b) it differs from the work flow up to now which leads to mistakes.

Additonal, admin can change the oder status multiple times. Or edit orders. There is no reliable way to track what has and has not been reduced automatically by the system.

There is a note added when auto-stock reduction takes place.

[saturday]

Manual orders are not that common.

I'm concerned that this claim isn't being substantiated by data either. We do a significant amount of manual orders, and order adjustments. Although my use case is anecdotal, the above thread proves there is more than likely solid justification here.

Perhaps we could find a more suitable tradeoff in the UX? For example, after a manual order is created or an order is adjusted, a modal, of which is in and of itself configurable to be automatically displayed, requires the administrator to either reduce stock, or otherwise.

In this scenario we're addressing the issue head on, which common or not, is inextricably linked to the use case in question.

[mikejolley]

I'm concerned that this claim isn't being substantiated by data either.

Ok let me rephrase then.

Manual orders are less common compared to frontend orders. We need to optimize the regular checkout flow over manual.

Perhaps we could find a more suitable tradeoff in the UX? For example, after a manual order is created or an order is adjusted, a modal, of which is in and of itself configurable to be automatically displayed, requires the administrator to either reduce stock, or otherwise

You mean force stock reduction in the users face? Or more options? Thats also not ideal.

For things like stock reduction, we need to be consistent. That is, stock is only reduced when a gateway calls "payment complete" or an admin manually triggers stock reduction. An order note is added in both cases.

Manual orders should be just that - _manual_. When you start mixing in automated events it confuses matters further. Give the admin full control to handle the order however the situation demands.

If your workflow is unique and needs it automated, fine. Add your own trigger in there. It can be done with code.

You should both know we're working on a new admin UI for orders - it's going to be much simpler to reduce stock in the backend when that drops.

[woodydeck]

@mikejolley Contrarian in a hopeless case are we? I can't say I'm free of stubborn opinions, but come on, one can form a pretty confident opinion from reading similar threads by merely googling. The only thing preventing me from wasting my time to drop the mic on you with a more scientific survey of threads (or a google war) is that woocommerce is not equal to other platforms that do not operate in the same way. There just are no threads supporting your argument, rather a handful of people congregating in this thread specifically stating their reasons why they are the <5%. It's a bit like saying rape doesn't happen in Rotherham while campaigning for Remain with your crusty todger out.

I wasn't arguing that nobody uses the manual order function in which the way you describe. I'm rather tolerant and open to the way people actually use things. I don't start arguments in the common with people taking the hypotenuse through the grass just because I stick to the rules and walk on the path. Every speed limit established must have a traffic survey every so many years without a posted limit to backup the limit, else it is unenforceable. You want to dispute my anecdotal claim? Fine, but I think you are the one who needs to backup with a poll. It's a quite obvious conjecture on my side.

Anyway m8, I found a workaround that was quite simple, but not ideal. Perhaps spend more time coding, and less time winding up yanks and the world of QA will have less bugs to nag you with. Cheerio.

[mikejolley]

Obviously if you look at threads like this or google for the same topic you're going to find people encountering the same issue, but that doesn't represent all users. There are cases where manual orders do not need to reduce stock, e.g. you're creating an order and sending the user a payment link (it's unpaid) and I feel it's better to have to manually reduce stock, than undo a stock reduction you didn't ask for.

Technically, the main issue for me implementing this is that order statuses can change multiple times, whereas payment is a one off event.

Additionally, if you are editing orders (which does happen) WC does not keep track individually of what has and has not been stock reduced. The stock reduction event does all items in the order.

These 2 points could lead to erroneous results.

I assume your solution doesn't cater for edits or multiple status changes?

[saturday]

You mean force stock reduction in the users face? Or more options? Thats also not ideal.

This is absolutely _more_ ideal than the current implementation. We're talking about a _manual_ solution with a disable option that addresses a workflow that is causing material loss on behalf of the stores this is effecting, which is any store that requires accurate stock levels. I can say in our case, we're talking about a meaningful material loss. In our case we found a process related solution; however we all know how brittles those can be.

Keep in mind this effects us when we're adjusting line items. I'm not suggesting a modal for all order adjustments.

In any case, you've stated your position and I appreciate the discussion. Off to the vendor branch we go.

[mikejolley]

p.s if you do have thoughts or suggestions on how to change things for the better, providing a solution is much better than steamrolling in with statements like this is a bug, you're all out of touch, _clearly_ this is obvious. Thats super annoying :)

@saturday More options are definitely not ideal. The user shouldn't need to make a conscious decision about how this should work.

How are you doing manual orders in your case? Payment offline, or sending links or what?

I guess we could trigger a reduction on the first switch to processing/completed status but not future changes, but as I said earlier, this is a 1 time thing. You cannot reduce stock multiple times which is why I'm fearing confusion.

[woodydeck]

It reduces the stock on processing. Not thoroughly tested and still working on it with someone so I can't answer that yet. There's also a way to manually do it without editing the core by clicking on the item. There is no need to go to the product page this way. It's still annoying, but somewhat logical.

This is a perfect thing to A/B test. Make options for both ways, default it to both ways, and have it send back results. Let democracy reign!

I'm sorry if I came off condescending, it's just annoying when developers think they know best because their solution is optimal for the way it works in their mind. I'm always blown away when someone fixes my peasant code with a solution I never even considered. There's certainly no reason for adding features for the fun of it, or to appease a small and belligerent minority, but given the passions of views, it is a case where you can obviously have both for this use case.

The last thing I will say in argument to you is that wordpress is modular (with overlap of many competing solutions), and woocommerce in particular is used by some of the most braindead employees that don't deserve to make a single bob, let alone minimum wage. You have to keep it consistent with the way the rest of the world does things whether you are a genius or not. This is why Trump speaks at a third grade level in public despite being among the more articulate executives, and this is why banks let grandmothers use password1936 to login and never nag them to change it.

[mikejolley]

This is a perfect thing to A/B test. Make options for both ways, default it to both ways, and have it send back results. Let democracy reign!

If this were a hosted solution we could :) But WC is self hosted so thats not really an option.

It reduces the stock on processing.

Is that the only status you use then? And you take payment offline?

[saturday]

How are you doing manual orders in your case? Payment offline, or sending links or what?

I'm not convinced that makes a difference. I think the more important question is at what order state do we expect stock adjustments to take effect? In our case, cancelled or failed orders should not effect stock levels.

More options are definitely not ideal. The user shouldn't need to make a conscious decision about how this should work.

This is literally how it works now. The user is required to make a conscious decision regarding how stock reduction works. I'm just posing a solution that will mitigate stock level inaccuracies by modifying the workflow.

I can see your concern about erroneous reduction. In our case, this feature would be most valuable where the line items have been adjusted manually, or if an order has been created manually. If a delta exists between the line item quantities, then a stock adjustment should be initiated for those effected line item products. In short, only do stock adjustments where the line items are new, deleted, or where a delta exists between order updates on line item quantities. This process could be manual, or in theory, automatic.

@mikejolley Does that make sense to you?

[woodydeck]

1) Some plugins scrape info to phone home on certain actions. I think it would only make sense for beta versions. The biggest hurdle is sample size, since I assume again the vast majority of people never touch manual orders.

2) I don't take payment offline if I can avoid it. We use woocommerce in an edge-ish way where we actually publicly print the nicknames of everyone ordering. It's a group product purchased with ~30 variations usually to be shared, and sometimes people ask for weird non-standard configurations of things on the fly, and a manual order is the best way. It's a bit nightmarish and easy to screw up inventory, so getting rid of one more step is helpful.

_Edit: The biggest risk for us is someone ordering an actually out of stock item. In this business it has much more negative consequences than an average business just overselling stock by a single item._

There are a lot of bugs with a lot of things in our customization so I am hesitant to post any solutions yet. Everything I get involved is a workaround of something, so it is again quite frustrating when I finally want to do something the ABC way but to have yet another roadblock from something I ASSumed was going to be standard. It's always a grind. :-)

[kelderkold]

Each single time i try to make a manual order it fucks up, I forget to reduce the stock manually and 5 mins. later another customer want to buy that (which are sold out)

So I found another solution, I only use the front end since the backend sucks up, that means that I manually has to write the customers name. (99% of my buyers are regular and registrated customers)
but at least i have the stock correct.

10% of my sale are on phone, customers calling with a problem, asking for a solution/spare part and just say, please sent it.

99% of my sales with invoice, I do not see the money before a sale, I just sent it.

So this stupid back-end solution are use less, I never in my intire life heard about a seller who sell anything and do not want the stock reduced. (if their is such a seller let me know why the hell they keep stock updated when they not using it)

[mikejolley]

Edit: The biggest risk for us is someone ordering an actually out of stock item. In this business it has much more negative consequences than an average business just overselling stock by a single item.

Sounds like you need a hold on that stock as soon as the order is made in backend, ignoring regular after-payment stock reduction.

AND stock reduction when status is processing/complete.

I think core already handles the pending order case so that part is ok.

I can see your concern about erroneous reduction. In our case, this feature would be most valuable where the line items have been adjusted manually, or if an order has been created manually. If a delta exists between the line item quantities, then a stock adjustment should be initiated for those effected line item products. In short, only do stock adjustments where the line items are new, deleted, or where a delta exists between order updates on line item quantities. This process could be manual, or in theory, automatic.

We'd need a way to track that... but what about the other way around?

If you delete an item from an order after stock has been reduced, what happens?

[saturday]

We'd need a way to track that... but what about the other way around?

There are numerous ways to do this, and you wouldn't need to use any persistence.

If you delete an item from an order after stock has been reduced, what happens?

I'm not convinced that would make a difference. You would re-add the delta qty to the stock levels. Because this would be done (manually or automatic) for each adjustment event, the total stock levels should be accurate.

[mikejolley]

Think it's more complex than that. Depends on deletion reason.

[wmnf]

It really is best to leave it alone I think after further review, there are just too many variables to auto-reduce stock. We are a non-profit and most of our manual orders are during fund drives when there are many. I created a new custom field as a Yes/No radio button for the user to select Yes when the order is complete taking away any control of the Order Status to admin only, then used the 'save_post' action hook in WordPress to recognize when the new field is Yes and trigger stock reduction, etc.

[mikejolley]

I think its safe to do the 'order as a whole' reduction as a one off on status change, but the individual line tracking seems over the top and confusing.

[saturday]

I think its safe to do the 'order as a whole' reduction as a one off on status change, but the individual line tracking seems over the top and confusing.

You'll be doing the same thing either way. You can't adjust stock quantities without monitoring line items as I suggested. Also, often a status may not change and a line item may be adjusted, in which case, you'll likely need to make the adjustments in scenarios other than status updates.

Finally, if an order is moved into a failed or cancelled state, you can treat each line item as the equivalent of a "removed line item" event - I am not sure if this is already handled by the core.

If none of the above is automatic, it will be necessary to prompt the user indicating that an adjustment may be necessary.

This enhancement is not necessarily trivial to implement, but I believe it is important.

[mikejolley]

You can't adjust stock quantities without monitoring line items as I suggested.

You can handle reduction. First time the order goes processing, reduce item stock. Subsequent changes or edits, leave stock alone.

[saturday]

Sure, you can do that, but it only handles a fraction of use cases and you'll still need to monitor line item quantities. This is true because it assumes that line items for orders that are on-hold or pending payment should not effect total stock.

[mikejolley]

Now you can see why I was anti-this change :D

[saturday]

Like I said, it's not trivial, and by extension, introduces potential for regression.

I'll look into adding this to my team's backlog for a forked vendor repository. If and when we get to this, I'll provide an update and share code. If someone else wants to take this on, go for it.

[mensmaximus]

I stumbled over this conversation while evaluating a solution for a customer who is in need of manual orders. From a developers perspective it would be pretty easy to "activate" automatic stock reduction for manual orders in the backend. But i agree with @mikejolley (after having read the whole thread) there are to many use cases for manual orders. I think the main idea of having manual control over an order in the backend is to modify orders on behalf of a customer or if something went wrong (wrong stock or price). Recalling my customers needs and reading what many people in this thread wrote I belief the workflow for "manual orders on behalf of a customer" is nothing that should happen in the backend. This is a perfect scenario for a plugin (like many other front end editors) to allow store owners, sales and callcenter agents to easily enter orders they receive by phone, email or while visiting a client.

[claudiosanches]

Don't forget that not even all payment methods reduce stock, like off-line methods...
I think we can add "Reduce stock for all items" and "Increase stock for all items" options in the "Order Actions".
But never make this a default behavior if you change some order to processing or complete.

[saturday]

Can someone give a concrete example of where you would not want to adjust inventory after the line items in the order have had their quantities adjusted, a new line item has been added, a line item has been removed or the order was created manually without the use of a "shop-as" type plugin?

[claudiosanches]

@saturday my example is easy:
You create the order, select ANY status, and when you need to save the order, you can just select:

No need to be automatic or linked only with one specific status.

And the same works just fine while you are canceling (refunding or anything else) an order, you can select the "Increase stock for all items" and save.

[saturday]

@claudiosmweb, I was more interested in a specific use case, and I still am. I'm still trying to understand why having the _option_ for automated stock adjustment doesn't make sense.

In any case, your solution seems to be the same as the current implementation; however the feature is moved to a more appropriate area, which at a minimum I agree with.

[claudiosanches]

@saturday here in Brazil we have something called "Boleto", you can generate it and pay in a bank, you don't need an account or anything else. So you can "pay" an order with "Boleto", but you have a few days to pay, in generally you can have between 3 to 15 days to pay... But when you pay, this takes like 2 days to be confirmed, but this can take more than 2 days, since don't count weekends or holidays (and in Brazil we have a lot of holidays).
So a guy can buy in your store and generate a "Boleto", he have 5 days to pay and pay on the fifth day, but is Thursday and Friday is a holiday, so the payment will get confirmed only on Monday or Tuesday.
Not to mention that don't any kind of commitment, your customer can get a "Boleto" and just not pay anything, so you need to wait for 10 or more days to cancel the order and restore your stock levels.
Well, so in some cases people generate manual orders and send "Boleto" for the customers, but not don't have any guarantee that will be paid, so you don't reduce the stock, reduce only when it is really paid and confirmed.
I bet that in more other places in the world have cases like this one and that's why I don't think we should force ALWAYS reduce stock when change to a determined status.

[saturday]

@claudiosmweb That's super interesting, and definitely answers my question.

Then the big question is, should we offer an _option_ to enable automatic stock adjustments, or simply continue with the manual adjustments?

What's Automattic's policy on configuration options for a scenario like this?

[claudiosanches]

No need for more an option, we are trying over the last years have less options in the plugin Settings.
And as I said, it not should be specific for ONLY ONE STATUS, you can reduce or increment with any status that you prefer. That's why I'm saying to use the "Order Actions".
And "the policy" is what the WooCommerce core team thinks what is better.

[saturday]

And as I said, it not should be specific for ONLY ONE STATUS, you can reduce or increment with any status that you prefer. That's why I'm saying to use the "Order Actions".

If you scroll up, I made that same point earlier this week.

And "the policy" is what the WooCommerce core team thinks what is better.

Great. I don't know why you have policy in double quotes. This is clearly a policy, if not some loose form of a policy, as per this comment:

No need for more an option, we are trying over the last years have less options in the plugin Settings.

In any case, I've made my point and I hope you guys take into consideration the amount of material loss this feature causes, which is largely due to the fact that there is no automatic adjustment option, or a more effective method of incorporating it into the order creation and adjustment workflow. I've described solutions for both.

Cheers.

[claudiosanches]

I don't know why you have policy in double quotes.

You received feedback from 2 core committers and you are asking it, sorry, but when I read seemed like you try to force something here, since you are not happy with what Mike and I are saying.

I hope you guys take into consideration the amount of material loss this feature causes, which is largely due to the fact that there is no automatic adjustment option, or a more effective method of incorporating it into the order creation and adjustment workflow. I've described solutions for both.

As I said, automatic adjustment is bad, not even all payment gateways reduce stock when the order is done. Not sure where you live, but looks like you made your point thinking only in your business modal. It's ok, I understand, and I'm only asking you to understand that I'm thinking in the entire world and more than one business model.

If you really need it, it's easy to do, no need more than 5 lines of code.
Create a plugin and show us how many people are using, this worth more than any justification.

[BlueValleyTech]

If it was really so simple, I don't see why the core developers are pushing back on this so hard. It is becoming apparent that they just don't want to implement this very basic function, that EVERY single client I have ever setup to us Woo Commerce with inventory tracking assumed should have been automatic.

Not sure where you live, but looks like you made your point thinking only in your business modal. It's ok, I understand, and I'm only asking you to understand that I'm thinking in the entire world and more than one business model.

A thread of 20 participants and 52 comments would seem to say otherwise. Speaking of business models, they are intended to be abstracted from the user interface. So why would anyone expect the business model to be entirely different when an order is created from the front end, vs when created from the back end? The business model should remain the same, regardless of what UI was used to create the order. The number one scenario for manual orders with ALL of my woo commerce clients is when a customer phones in an order. This is a very common scenario. The person handling the call enters the order from the back-end. Why should inventory be treated any differently than is the customer went to the website and created the order themselves.

And sure I have educated the need for them to manually adjust inventory. And most of the time they remember to do this, although none of them like it. And they are usually people with multiple roles, so when something happens that pulls them away form the computer, say answering the delivery door, helping someone else, etc. Mistakes happen and it is VERY common for the inventory to be off. Usually those mistakes are tracked back to back-end orders where they forgot to manually adjust stock.

As I said, automatic adjustment is bad, not even all payment gateways reduce stock when the order is done.

That is just further evidence that the inventory management for Woo Commerce is sorely lacking. Why should the payment gateway used by the customer make a difference in how stock is tracked? That simply does not make sense.

I realize at this point that us real world users will probably never convince the developers, who are grasping at any reason they can find to not work on this. They obviously do not want to spend any time on building a robust inventory tracking system, like so many of their competitive commerce systems have (and need). That is probably why the current system is as shoddy as it is.

Instead they grab reasons like "We need less options!", and "Manual control gives ultimate flexibility!". Well if those blanket statements are true, why don't we just clear out ALL options from the plugin Settings. For that matter, maybe the entire system should be replaced with a rudimentary text editor, allowing the back-end people to simply jot notes for the orders in whatever fashion suits them! That would give ultimate flexibility for any business model, right!

I give up. I had originally thought Woo Commerce was the best choice for WordPress E commerce, due to flexibility and ease of customization with hooks, etc. But it is becoming clear that the developers are not interested in hearing what the customers actually want. Instead they will point at a couple obscure business models and use them as justification on why they don't need to improve anything.

[claudiosanches]

@BlueValleyTec for sure you have not read absolutely nothing here, no one said that we do not want to improve how this works, I personally don't agree in make it automatic, since don't works for everyone and still mistakes can be done if force this behavior for every order, but I agree that we need to improve and I give options for it.

This issue is assigned to WooCommerce 2.8, so we'll make improvements about it. But I'm closing this thread for new comments, since this is scaling and going out of the subject of this discussion.

[claudiosanches]

For those who want to reduce the stock automatically, it is now possible with this plugin: https://github.com/claudiosmweb/reduce-stock-of-manual-orders-for-woocommerce

[mikejolley]

Closed in favour of https://github.com/woocommerce/woocommerce/issues/13359