View Issue Details

IDProjectCategoryView StatusLast Update
0007222OXID eShop (all versions)1.01. Products (product, categories, manufacturer, promotions etc.)public2024-02-05 10:49
Status acknowledgedResolutionreopened 
PlatformPCOSLinux DebianOS Version9
Product Version6.2.3 
Target VersionFixed in Version 
Summary0007222: Stock increase after cancellation, on 0 stock product with no negative stock allowed

This issue is related to the other one that has been declined :

When we place an order on a 0-stock product, then cancel it, the product stock is increased to 1.

This happens wether the "allow negative stock" is on or off.

Is this supposed to happen like that ? because it's confusing for the shopowner if the stock is wrongly increased.

Thanks for your help

Vincent Boulanger
Steps To Reproduce- Set a product to oxstock 0, delivery : standard

- Master settings -> core settings -> settings -> stock -> "Allow negative Stock Values" is *disabled*

- Place an order, even with Vanilla payment methods

- Cancel the order in admin

- check oxstock of the product, it got increased to 1
Additional InformationI've tested it right now in the demo shop provided by this platform.
ThemeNot defined
BrowserNot defined
PHP VersionNot defined
Database VersionNot defined



2021-03-25 14:21

administrator   ~0013403

I also just tested it and as also in bug 0007220 mentioned, the behavior is not reproducible.
I have enabled "allow negative stock" levels, entered the item (see screenshot) with stock level = 0. I then ordered the item and cancelled the order.
As expected, the stock level is zero again.

- es -


2021-03-25 14:22


Lager_1.JPG (34,874 bytes)
Lager_1.JPG (34,874 bytes)
Lager_4.JPG (43,646 bytes)
Lager_4.JPG (43,646 bytes)
Lager_5.JPG (64,989 bytes)
Lager_5.JPG (64,989 bytes)
Lager_2.JPG (51,510 bytes)
Lager_2.JPG (51,510 bytes)
Lager_3.JPG (55,691 bytes)
Lager_3.JPG (55,691 bytes)


2021-03-25 14:31

reporter   ~0013404

Last edited: 2021-03-25 14:32

View 2 revisions


Thank you for the test and the answer.

I guess my first writing was not accurate enough, sorry.
Indeed it works as expected when the "allow negative stock" option is enabled (my mistake here)

But the current problem faced is when "allow negative stock" is disabled. I specifically mentioned it in the "steps to reproduce" section.

So the question stays :
Is it normal, with "allow negative stock"=OFF, that the product with 0 stock ends up with stock = 1 after order placement and cancellation ?
I must add that the initial issue faced by our partner was stock getting increased after payment declined, which is tougher to test with vanilla methods (hence the test with order admin cancellation)

Sorry for reopening, and thanks in advance for explanation or further investigation.

Best regards,


2021-03-26 09:14

administrator   ~0013405

The problem lies here: If the option "allow negative stock" is not activated, the OXSTOCK status would also have to be saved before an order, because if OXSTOCK = 0 or 1 after the order the OXSTOCK = 0. If this order would then be canceled or rejected due to rejected payment, the OXSTOCK status before the order would have to be used:
- Status before order OXSTOCK = 0 -> - Status after order OXSTOCK = 0 -> no Inc(OXSTOCK)
- Status before order OXSTOCK = 1 -> - Status after order OXSTOCK = 0 -> Inc(OXSTOCK)

If the option "allow negative stock" is activated, the described problem does not occur at all and the OXSTOCK is also calculated correctly in this case and it is not necessary to save the OXSTOCK before the order, because an Inc(STOCK) can always be made.


2021-03-26 10:16

reporter   ~0013406

Thanks for explanation, that's what I felt the actual behavior was.

So if I get it right, there no existing mechanism to prevent the increase after cancel/rejection, if "allow negative stock" is not activated and stock was 0 ?
Then it is on the module development responsability to save the information about 0 stock and restore it after it got increase ?

For a payment module, it should be doable within the extended processes I guess, but I'm wondering how shop owners with vanilla installation would deal with this case.