2

It seems system product stock and real stock are not in-sync.We have matched real stock and product stocks on System several times, still it gets differ after some period of time (weeks/days) it's just matter of time.

I know this is a silly question. I don't know how to reproduce this but we experience this issue for a long time. What do I need to know, what could be the possible reason for this? What can I do to prevent this? Is this is a known bug?

I'm using Magento 2.1.

  • 1
    This is a result of Index's had a similar issue i set the index for stock to update on save to prevent this so far it has worked fine but still keeping an eye on it may have to extend checkout to run reindex on stock after order – Dava Gordon Sep 14 '17 at 15:52
0
+100

Possible reasons :

1.

When you have your index on schedule you need to configure a Cron Job. A wrongly set cron job can result in frontpage desyncs (not backend desyncs).

More information on Crons page of Magento

Short explenation : If you use a Webhost ask them where to put the .crontab file and how they read it. In the Crontab you need to define how often and where it needs to use which commands and where to log it :

Mine :

*/5 * * * * php /site/www/bin/magento cron:run >> /site/www/var/log/magento.cron.log&
*/5 * * * * php /site/www/update/cron.php >> /site/www/var/log/update.cron.log&
*/5 * * * * php /site/www/bin/magento setup:cron:run >> /site/www/var/log/setup.cron.log&

site/www is the default root path of my magento installation. Also be sure your index configurations in your admin section are matching this since they queue what to do in your database cron_schedule

2. --> !!!

Deleting Invoices/orders/credits.

I noticed that you first need to cancel an order/invoice before deleting them. If you do not do so the stock won't be put back. This can result in a different Stock after a while.

So just never delete something. Create an invoice when its sold and if it returns make a Credit like you should. Do not delete orders but cancel them and then delete them.

If you have any modules that delete orders or anything like that they need to cancel it first too!

3. Write access database. Well if your database is not updating at all you should check permissions and see if the user you are using has indeed writing rights in your database. This would give an error on installation and every save though so its a long shot.

4.

Front-end desyncs can also occur if your cache permission is not well configured.

Propably number 2 is causing your issue but the other things i added as extra information.

Let me know if 2 is the case for you. Usually is.

  • Thank you for the long explanation!, I'll accept this one after review. My cronjob failed due to this error github.com/magento/magento2/issues/4911 For now I've setup Contab as follows: */1 * * * * /var/www/html/magento/bin/magento index:reindex cataloginventory_stock Hope this will help to resolve the issue. – Dasun Sep 16 '17 at 8:14
  • Well just a question. Is your magento installation really located within global path var/www/html/magento/ ? So if you go from your absolute root directory (if you have a webhosting you need to ask them since often you can not see the global path) you have the folders : var->www->html->magento->magento installation – CompactCode Sep 16 '17 at 13:23
  • Als do not forget to put 'php' in front of it – CompactCode Sep 16 '17 at 13:25
  • The reason why is because a normal ssh command is 'php bin/magento do:something'. But since the crontab is working from your root directory you need to specify the path to the bin folder. For me this becomes 'php /site/www/bin/magento '. Also i would never put it on 1 minute since thats to much. It might take longer then a minute to complete the tasks and then you have the problem they will error because they overlap. Give them 5 minutes at least. You can see in your cron_schedule database table if they executed correctly – CompactCode Sep 16 '17 at 13:28
  • Well, I've made bin/magento file executable. if I run that command in the bash it will run perfectly without using php in front of it :) I can confirm that Stock Indexer cronjob is working as expected by reviewing "Index Management" sections "Updated" value. – Dasun Sep 17 '17 at 14:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.