Problem with product quantity being exceeded

  • Posts: 6
  • Thank you received: 0
6 years 4 months ago #295686

-- HikaShop version -- : 3.5.1
-- Joomla version -- : 3.8.10
-- PHP version -- : 5.6.36
-- Browser(s) name and version -- : Firefox 61.0 (64bit)
-- Error-message(debug-mod must be tuned on) -- : None

Hi guys,
First off, thanks for the wonderful product. We have been using the free version of HikaShop on a non-profit website for four years.

Our shop is used once a year for about 15 minutes to sell tickets for an event. About 270 - 300 tickets get sold very quickly and website gets hammered pretty hard.

The last two years we have had problems with the tickets being oversold by up to 5%.

I've tried changing the configuration so that the product quantity is updated at check out and tried updating the product quantity on cart update. From memory, setting the product quantity to update on cart update option worked better, but we still oversold by 1%.

Could this be due to two or more people updating their carts at the same second, effectively tricking the shop into thinking there is more products left than there actually is?

Hopefully I have just missed something obvious in the config.

I've been keeping the HikaShop version up to date each year.

I'm not using any extensions in the shop at the moment, but I might try to use an electronic ticket plugin for this years sales.

Anybody had any similar problem? I've tried looking around on the internet, but couldn't find anybody with the same issue.

Please Log in or Create an account to join the conversation.

  • Posts: 82867
  • Thank you received: 13374
  • MODERATOR
6 years 4 months ago #295705

Hi,

If the stock of the product is 0 at the moment the order is created, then the order creation will be cancelled and the products removed from the cart (HikaShop 3 or newer with "checkout legacy" setting turned off).
So the only way to get products oversold is if you configured your HikaShop to update the stock of the product when the order is confirmed and not when the order is created. In that case, it's possible to create plenty of orders of a product even if the stock of the product is 1. As long as one of the orders is not paid (and thus not yet confirmed), the stock will stay at 1.

So you need to check the setting "Update the product stock on confirmed status" and make sure it is turned off so that the stock is updated when the order is created, not when it is confirmed.
In such case, you might actually have left overs if people don't pay for their orders. So you can have the "order auto cancel" plugin cancel automatically the created orders not paid after a certain amount of time. That will give back the stock upon cancellation of the orders.

The following user(s) said Thank You: developer

Please Log in or Create an account to join the conversation.

  • Posts: 6
  • Thank you received: 0
6 years 4 months ago #295711

Thanks for the detailed explanation Nicolas.

I eventually worked out that if the product stock is updated on order confirmation instead of product added to cart, then that would cause an oversell after the first time it happened.

I've checked the settings you mentioned to see what they are set at:

  • 'Legacy checkout' is set to 'No', but I may have only just set that this year after updating to HikaShop v3.x. Previously this setting wasn't in HikaShop 2.x right? Could the legacy checkpout have caused my problem, or is that unlikely?
  • 'Update the product stock on confirmed status' is set to 'No'

I’ll also turn on the extension plugin for auto cart cleanup, thanks for mentioning that.

I've also considered that it might not be a problem/bug with HikaShop, but because the server is overloaded.

It might be time for me to test the full HikaShop checkout process in payment sandbox mode with a load tester.

Thanks again for your response.

Last edit: 6 years 4 months ago by developer.

Please Log in or Create an account to join the conversation.

  • Posts: 82867
  • Thank you received: 13374
  • MODERATOR
6 years 4 months ago #295723

Hi,

Having the legacy checkout to no is good. That means you're using the new checkout. However, it shouldn't have an impact on the stock management.

Well, if the load is really high and that several people order the same product at the same time, it's potentially possible that when a customer clicks on "finish" on the checkout, between the time when the cart is loaded into memory and the stock checks are done, and the time the order is created in the database and the stock is updated, someone else could have clicked on the "finish" button and the cart be already loaded in memory with the stock checks already already done.
This normally happens in a fraction of a second, so the probability of that happening is really low, but not impossible. One percent of oversell seems quite hight to me but if the server is running to a crawl, then that fraction of a second might transform into a few seconds and in that case, that could explain that one percent of oversell.
In that case, I see several things you can do:
- use a more powerful server which can better take in the load.
- The email sending process can require a lot of resources and can potentially be the main cause of the server load. So you might want to see how this can be optimized (like using a 3rd party email sending service, etc).
- You could potentially write a plugin implementing the onAfterCartProductsLoad trigger and directly update the stock at that point if the parameters in $_REQUEST indicate that the "finish" button has been clicked and then reupdate the stock back after the order is created to avoid double decrementing the stock.

Please Log in or Create an account to join the conversation.

  • Posts: 6
  • Thank you received: 0
6 years 4 months ago #295766

Thanks again for a very detailed reply Nicolas.

Lots to think about there. We are considering doubling server capacity, which might be the easiest way to go.

I never gave a thought to the emailing of order details as something to load the server heavily, thanks for mentioning that.

I think I've got enough to go on to fix up our problem, you've been very helpful :)

Please Log in or Create an account to join the conversation.

Time to create page: 0.062 seconds
Powered by Kunena Forum