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 checkcataloginventory_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]:
- Image 1 –
catalog_product_entity
– Filtered products 2x different configurables (one with simple products / other with virtual products)
- Image 2 –
inventory_source_item
– same SKUs and theirstatus
.
- Image 3 –
inventory_stock_1
– This is a View, so I assume as you mentioned whenreindex
happenscataloginventory_stock_status
gets impacted, so the view data returnquantity = 0
.
- Image 4 – Joined data for
attribute = 'status'
Best Answer
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%
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.