As far as I can tell, the "model" in the uc_product_adjustments schema is a sku that combines the product sku and the options chosen for each attribute.
I don't think it actually "combines" the product's primary SKU with anything - it holds whatever SKU you supply as the alternate SKU for a particular set of options for a product. I suspect there's no uniqueness restriction either - it might or might not match any other SKU (also known as "model") in the system.
Here's my current understanding of the relationship between SKUs and products:
- One product can have several SKUs. This happens when you assign an alternate SKU to a certain combination of options in the "adjustments" tab.
- One SKU can be assigned to several products. This happens when you simply give two or more products the same SKU. I can think of a couple of reasons why you might want to do this. One is the student-pricing scenario in #7 above. Another is if you have, say, a box of 10 widgets. You might want to sell them individually for one price (product "A"), but a whole box at a discount (product "B"). On the shelf, however, you only want to have to deal with one SKU, and you just keep one box open to cater for the one-off purchases.
Given this arrangement, it's difficult to get the stock level into
products.csv cleanly. It raises the possibility of duplicate SKUs on import, and the ambiguity that then arises with stock levels . Getting stock levels into
product-optiuons.csv would be even harder.
When I download the "stock" csv from your module, it only includes the primary SKUs, as you said, but I need to be able to edit the "stock" of the sub-skus.
You will need to have set the stock for the alternate SKU to be "active" before exporting the stock levels CSV. I'm pretty sure this goes for the primary SKUs too