Those who have large data sets consisting of variable products and multiple variations who don’t wish to use an SKU to reference the variable product are kind of screwed.
You can’t perform a first-time import of variable products and variations without assigning the variable product, or parent, an SKU that can then be referenced by each associated variation. And that has forced us to construct a backend query that blanks out the SKU after importation.
Why would one want to not have variable products displayed with an SKU? For one thing it’s an inconsistent construction. The variable product with variations is really a class container and not a product. The variable product’s SKU is not a property of the class as are variations. Secondly, it confusing to see a reference to an SKU that you can’t purchase and even when you have your default attribute set to ‘unselected’ the shop still shows an SKU, an SKU of something that can’t be purchased. It doesn’t make sense. A blank SKU shows as ‘N/A’ on the shop, which is preferable to showing an SKU that can’t be bought, but still it’s inconsistent. Nothing should be displayed in that location in the shop for variable products until a selection of a variation is made.
A more logical way to perform the import and accommodate the above concerns is to include a new column called something like family_id. When the line item is of a variable type then the id is referencing the parent, when the line item is of a variation type then it’s referencing a child of the parent. This id is temporary and only used in the import process. The scheme lends itself to the parent->child relationship of the dataset so the id would an easy thing to construct in the preparation of the csv import file.
Open
Last updated: February 21, 2019
0 comments
Log in to comment on this feature request.