Quote Originally Posted by ttfan View Post
Thank you so much for looking into this. Sorry I've taken so long to reply, but I'm struggling to get my head around how this works, as I'm no programmer.


Yes that is correct


We don't have high volume sales, and although we have a large catalogue of item, we only have small quantities of each. We keep double records while we're testing, which is how we know it's failing regularly.


It's highly unlikely multiple orders were placed at the same time, as out shop is low volume, and in most cases different items are purchased.
All of the "consternation" is understandable. There's a lot of things that have to fall together to first even get results, then there are a number of twists and turns that could exist and explain why one feature or another doesn't work as expected.

From the description of the setup, right now I'm considering without additional "this is how I can make it happen again" data, that the issue is either out-dated code because there was a period around Oct 11th, 2016 when the stock decrement calculations/actions were changed with the expectation of handling the decrease of stock for any type of "allowed" variant combination. In your case, it appears that a variant is a single entry, no combinations with other things.

Couple of answers to questions can help resolve the issue, the first is to identify if the code contains expected information. If you could please access the file: includes/classes/observers/class.products_with_attributes_stock.php and then around line 442 possibly as far down as line 489, look for the function: updateNotifyOrderProcessingStockDecrementBegin.
If you could please copy the code of that function.
Then if you could reply to this message, select the # symbol in the message box toolbar to generate [CODE][/CODE] tags. The cursor should be between the two of those tags, and then paste the code.

So another question is how is the includes/classes/order.php file different from the standard/vanilla version of that file?

What other plugins are installed?

When looking at the product, purchases, type of product in the order(s), etc, what commonalities are found? Did the lack of decrease observed have anything to do with the remaining amount and the amount purchased? (ie. Was that the last available quantity and it didn't go out of stock, or any other information to help.)

Do the product have a maximum and is it limited by a mixture? Ie. Is there a case involved that limits the total quantity that can be purchase say to 5 and the customer can pick a total of 5 of the associated items, but only a total of 5, not 5 of each type of attribute? That type of thing.

Another relates (though I don't think it would be a specific reason for the issue) is the setting of using Dynamic Dropdowns, is it as most robust set to be active only when multiple attributes are involved?