Magento 2.3.5 - Data Migration - Products out of Stock Criteria (Configurable Products mostly)

Question

Another issue regarding data migration from Magento 1.7.0.2 to Magento 2.3.5.

Question:

• What are the conditions for products to display 'out of stock' in Magento 2? I am clearly missing something!

Description:

I see that all the configurable products now show 'out of stock' when going to the product page on Magento 2. I am unable to figure out what conditions are used for displaying 'out of stock'.

Basically, I want to ensure that the configurable products show their simple related products in the dropdown options (Magento default themes). The options are not currently shown because of this issue.

I tried the following:

• Checked Tables inventory_stock, inventory_stock_1, cataloginventory_stock_item, cataloginventory_stock_status, inventory_stock,cataloginventory_stock_status.
• Only cataloginventory_stock_status has qty of 0.
• None of the tables that use stock_status are ever set to 0, everything is always 1.
• I even ran update quantity on cataloginventory_stock_status:

UPDATE cataloginventory_stock_status SET qty = 999999 WHERE qty = 0;

• Refreshing after clearing cache still showing out of stock, then immediately after reindexing bin/magento indexer:reindex I check cataloginventory_stock_status again, the qty value is set back to 0!

Also:

• I noticed that the cataloginventory_stock_status_idx table is always empty even reindexing. Is this table even used?
• I have also tried to see the effect of Manage Stock = 0, but even then those products still show 'Out of Stock'.

I would really appreciate a solution where I can run MySQL queries (since this is a data migration) if possible.

Thanks!

[Update - 2020/05/28]:

Does anybody have any advice regarding this please.

• I have been unable to get migrated configurable products to work (still remains out of stock).

• The issue: I cannot just delete/reimport products - I need to eventually bin/magento migrate:delta so changing the ID sequences will break delta migration later on from the source database.

(The screenshots here are because of the comment below from @LitExtension Magento Migration). Only two configurable products are shown - one with 'simple', other with 'virtual' products, because they appear first in my SQL results.

I do not know what is wrong. Please see if there is anything I'm missing, or what else I need to supply information for.

NOTE: - I do not have is_in_stock attribute mentioned. The query returns no results.

    SELECT * FROM eav_attribute ea 
    WHERE ea.attribute_code = 'is_in_stock';

[Update Images]:

1. Image 1 - catalog_product_entity- Filtered products 2x different configurables (one with simple products / other with virtual products)

2. Image 2 - inventory_source_item - same SKUs and their status.

3. Image 3 - inventory_stock_1 - This is a View, so I assume as you mentioned when reindex happens cataloginventory_stock_status gets impacted, so the view data return quantity = 0.

4. Image 4 - Joined data for attribute = 'status'

Answer 1

I'm currently tracing around a similar problem and I found your question hoping for answers.

Data migration is magic but the magic isn't 100%

1. it sometimes lags when main Magento makes structural changes, creating wrong data
2. it sometimes misses that certain defaults have changed for data when it recreates it on migration, so every delta can ruin it
3. some attributes and properties (eg: product grid properties of attributes) are no longer visible in admin but still exist behind the scenes, and if they are not set right by migration you will have problems
4. Magento inventory itself is in an evolving hybrid state between the old "cataloginventory" and the new MSI "inventory" and sometimes there are changes that leave gaps, until next fix. Or break things (eg: reservations table format changed)
5. Some modules still only use the old system or even straight to the tables and they can mess things up
6. data migration when I ran it put the product stock in the default stock and old tables - even though I had MSI enabled and set up. It might have cleverer options now. In theory if you use MSI you just need to "move stock" from default stock to real stock in the product admin after you run first migration (it could keep updating that default stock though, if stock is in delta. I'd disable it and do a stock import at the live point)

I know you say you cannot add/remove products because of delta but you need to be able to test things so either create a clone to test on, or do database backups that you can restore to state.

You really need to manually create a new product on your new site, and see if it goes in stock happily. You can delete it when you are done with the investigation That wont mess delta.

If the new product also doesn't show in stock, it's a different problem and need to make sure nothing is missing in the stock tables and views, and crons are running and indexes etc.

But if the new product shows in stock, that is the case, you can then compare that product's entries in stock tables (both the cataloginventory_ tables and the inventory_ tables AND the inventory_ view plus the ) but also eav attribute tables to find the difference between that product and the non working ones.

Then you can figure out what needs to change in your mappings, or where to look for the culprits.

In my case that I havent fully figured out yet product stock is fine, until it hits zero.

Then the stock status changes in the cataloginventory_stock_item table and when I get stock in and update the stocks then the new MSI system tables all show this in stock, but the cataloginventory_stock_item field stays 0. I think it should go to 1 automatically so am currently checking through the code tree where it should change and why it doesn't and whether it is a module, bug or what.

I have a suspicion that the field in that table called 'stock_status_changed_auto'might be part of it. When the old code sets a product out of stock (deprecated routine 'updateSetOutOfStock' in CatalogInventory\Model\ResourceModel\Stock.php) is is supposed to set both is_in_stock to 0 and stock_status_changed_auto to 1. Then the counter 'updateSetInStock' checks for products that are in stock but have is_in_stock to 0 and stock_status_changed_auto to 1 and change is_in_stock to 1.

The products which are put out of stock on my system do not get the stock_status_changed_auto to 1 so even though that code is deprecated maybe it is part of the problem.

Fixing it temporarily is as easy as changing that is_in_stock value in the table, but making it not happen at stock update import is another matter altogether

Fingers crossed yours is easier to spot

PS: as an aside, unless you absolutely need the history of all category urls, remove the "use category in product url" url rewrites setting or remove that step from delta - it is the main cause of hangups I have had in delta, until I removed it. Delta can handle orders and product tables being not exactly in sync and still migrate changes, but it dies a lot updating that url rewrites table if you even move a category on the new site.

PPS: It all depends how many changes you made to your migrated site already but it might be easier to redo the migration from start on a fresh one, once you have figured out the issues, modified the config, than to manually fix all the wrong data. If you have made significant configuration changes that can be exported and reimported. If you've added lots of data, made CMS changes, at some points it becomes too much. But if you haven't yet, you can get your migration right back by rerunning it with the start over flag.

Answer 2

There are many factors which determine the qty. If it is Configurable, the qty will depend on simple products.

Updating the cataloginventory_stock_status table does not make sense because after you reindex it, this table would be gen following to the cataloginventory_stock_item table. In this table, if qty is not equal to 0 and is_in_stock = 1, you should check in the inventory_source_item table whether there is any data or not.