I’ve split this into a new topic as it is turning into a slightly different discussion than just how to do an import. 
–
First off all, using Collections is not a requirement for the Product List - it’s a suggestion to make the resource tree more manageable if you have hundreds or thousands of different products to manage. Using Collections also does not mean you have to use the product list, that’ll also work fine with other approaches.
If you or your client find Collections difficult to use and expect less than let’s say a dozen products in a dozen categories each, the regular resource tree will work fine and you can just forget all mention of Collections.
–
It’s best to think of Commerce as an addition to your existing MODX site. An extra layer.
First you build your content, the pages (resources) in MODX that determine how you promote your products. You can use Collections to manage categories that hold a lot of product pages if you want to, but if you just want to use a normal resources, a single resource that shows all your products, or not even any resources at all: that’s absolutely fine.
This first part is what we refer to as the “product catalog” - you can build that any way you like. We offer suggestions but they’re just that, suggestions. Some people have also built entire custom catalog solutions with their own routing and retrieving information from third-party systems to show on the resource pages.
–
Next up, you add the Commerce layer to provide the relevant bits of product information (notably things like product name, sku, price, and stock) to Commerce. This is the part we refer to as the actual products. To fit different needs and types of projects, we currently offer 3 built-in ways to tell Commerce what it needs to know about your products:
-
Product List TV. Unless there’s a good reason to prefer one of the other options, this is recommended for its simplicity and flexibility. It’s easy to integrate into your templates with the commerce.get_products snippet, supports custom product types, and can hold any number of “variations” of a single product that should be on the same catalog resource. It supports all of the features in Commerce, including custom product types. It also works just fine with a single product per resource (in fact you can limit the TV to only allow 1 product if you want to).
-
Product Matrix. This is for the specific use case where you have two dimensions for which a single master product is available. The typical example is clothing: a certain t-shirt model comes in a variety of sizes and colors, and you don’t need separate pages in your catalog for each unique combination. In the matrix you can define those dimensions and easily hold dozens of unique product combinations.
-
Resource Product. Rather than using a custom interface to insert the product information for Commerce, it can load it from your resource information directly. While this is easy to use (especially if you already have the product information in resources before) and prevents duplication, it’s more restrictive. The resource product approach does not support custom product types (like the digital product, multilang or imagemeld extensions), custom shipping/shipment types that require additional information on a product, and you also have no way of adding an additional variation to a single resource (unless you add a product list TV).
(Technically there’s also the 4th option, managing products directly in the Commerce dashboard, but that’s a rather niche use case for shops with only a handful of products max.)
Because of the restrictions of the resource product, I don’t generally recommend using it unless you truly understand what you’re restricting yourself to, and are absolutely certain your shop’s requirements aren’t going to change to require more functionality in the future. Resource products sound like an appealing option on the surface, to reuse what you may already have on the resource itself, but you are quite significantly limiting what functionality is available to you.
–
Especially on a first build with Commerce where you’re still learning all the things it can do and how it works, go with the product list instead. I’ve seen enough people having to go back and change their setup when they got further in the project and realised that they did in fact need more functionality than the resource product approach can offer.
–
When using the resource products approach, I would recommend enabling the “Hide Products” module to get rid of that section entirely. As Commerce retrieves all relevant information from the product, and no longer offers any useful editing outside of the resource, getting rid of that tab entirely is better for the user experience.
Commerce will load the stock and other data directly from your resource when rendering it (eg when adding to the cart), so while it shows incorrectly in the dashboard it will still use the latest value in the front-end. Saving the resource product also triggers a full synchronisation for convenience but is not necessary to do after each change.
