Bulk-edit product fields in a spreadsheet

Two things decide whether your cost ledger starts out right: what your suppliers call each product, and what each product cost you. Both live on your Shopify products, and on a catalogue of any size neither is something you want to type in one variant at a time.

This file sets all of it in one pass.

Why this tool exists at all

Shopify's own product CSV covers product fields. It does not cover variant ones. Their documentation is blunt about it:

Variant metafields aren't supported for product CSV import/export.

That matters here because a SKU is per variant, so the supplier's code for it has to be per variant too. It is precisely the field with no built-in bulk path. Without something like this you are left with the in-admin bulk editor or a paid third-party app.

Before you start: create the two fields

You only do this once. In Shopify go to Settings → Custom data and add a definition of type Single line text in each of two places. The level is the part people get wrong, and it is the part that matters.

| Add it to | Call it | Why there | | --- | --- | --- | | Products | Supplier Name | A product comes from one supplier. Repeating the name on every variant is a copy that can disagree with itself. | | Variants | Supplier SKU | Each variant is a different thing your supplier sells you under a different code, so each needs its own. |

Name them whatever suits you. Landara matches on the identifier Shopify generates behind the label, so renaming "Supplier SKU" to "Vendor Code" later changes nothing.

Export, edit, import

Nothing is written until you click that last button. The step before it is a count of exactly what will happen.

The columns

| Column | Edit it? | What it is | | --- | --- | --- | | Variant ID (do not edit) | No | How Landara knows which variant a row belongs to. | | SKU (do not edit) | No | There so you can read the file. This tool does not rename SKUs. | | Product (do not edit) | No | There so you can read the file. | | Cost per item (USD) | Yes | Shopify's own cost-per-item field. The heading carries your store's currency. | | Supplier SKU (variant.metafields...) | Yes | Your supplier's code for this variant. | | Supplier Name (product.metafields...) | Yes | Who supplies this product. |

Each metafield heading says whether the field belongs to the variant or the product, because a store can define the same field name on both.

Choosing which columns you get

By default the file carries the two supplier fields Landara knows you use, plus cost per item. Choose which columns to export opens a list of every text field your store has, so you can add the ones you want and leave out the ones you do not.

Most stores have text fields that have nothing to do with costing. Leaving them out keeps the file short enough to read, and short enough that a stray paste has nowhere unhelpful to land.

The three read-only columns fail differently

They are worth telling apart:

• Variant ID: delete or overwrite it and that row is skipped and reported. Anything you typed on it is not applied.
• SKU: change it and Landara stops the whole import and names the rows. People reasonably assume editing that column renames the product. It does not, and a SKU rename moves what your cost history is filed under, so it is done deliberately in Shopify rather than as a side effect of editing another column.
• Product: ignored entirely.

A product field repeats down every row of its product

Supplier Name belongs to the product, so a product with five variants shows the same value on five rows. Change it on all of them or none.

If two rows of the same product disagree, the import stops and names the product. Picking one silently would throw away an edit somebody made on purpose.

Cost per item

This is a real Shopify field, not a Landara one. Whatever you put here is what your store will hold, and it is the figure Landara reads when it values the stock you already own.

Currency symbols and spaces are fine: $249.00 and AUD 249.00 both read as 249.00. Values are stored to two decimal places, and Landara tells you which rows it rounded.

A blank cell leaves the cost alone

Landara sets costs. It does not remove them. If you clear a cell that had a value, that row is held back and named rather than written as blank or as zero, and the summary tells you where to clear it in Shopify instead.

The same is true of the supplier columns. An emptied cell is never treated as "delete this".

Then bring the codes into Landara

This is the step people miss, and it is worth being clear about: writing the file to Shopify does not put anything into Landara. Shopify now holds your codes and your costs. Landara has read none of it.

That saves the links and nothing else. No cost layers are created and no costs change, so it is safe to do at any point, and it means the next supplier invoice you upload already knows what their codes mean.

The order to do all this in

So:

1. Export this file, fill in the costs and the supplier fields, import it back.
2. Read from Shopify on the Supplier SKU links card, to bring the codes in.
3. Only then run Start setup to take the opening baseline.

The costs you set in step 1 should be as close as you can get to what your accountant currently carries that stock at, because step 3 is what puts them into your inventory valuation. See Seed your cost layers.

What the summary tells you

Before anything is written you get a count of each outcome:

• fields will be written and costs per item will be set: what is about to change. Counted separately, because they are two different writes.
• already hold exactly this: rows in the file that match your store.
• cells were emptied: held back, not cleared.
• costs will be rounded: values with more decimal places than Shopify stores.
• rows name a variant this store does not have: skipped and reported.

If a cost cell cannot be read, nothing at all is applied, including the supplier fields, and the offending lines are named. A cost column that will not parse is almost never one typo. It is usually a locale or a currency format applied down the whole column, and applying the half that happened to parse would leave you unable to say what landed.

Troubleshooting

A product is missing from the file. Products with no SKU are left out, because the whole file is keyed on data hung off SKUs. Landara names them when you export. Give them a SKU in Shopify and export again.

"This store has no text metafields." You have not created the definitions yet. See the top of this page. You can still use the file to set costs in the meantime.

Only some of my fields are in the file. Two reasons. Only single-line and multi-line text fields are offered at all, because a number, JSON or reference field edited in a spreadsheet cell would produce something that looks right and is not. And the export defaults to the fields Landara knows you use: open Choose which columns to export to add the rest.

Landara will not change my product titles. Correct. Landara never edits your product data beyond the fields in this file, the cost, and products it creates for you from a supplier invoice. Titles, descriptions, vendors, tags, images and SKUs are yours, and Shopify is where you change them.

The import is slow. Setting cost per item is one call to Shopify per variant, so a large catalogue takes a while. Landara sends them in batches and shows progress on the button. If something fails part way, it tells you how much had already been written.

I edited a product in Shopify after exporting. That is fine. Landara re-reads your store at import time rather than comparing against the file you downloaded, so your more recent edit is never overwritten by an older copy of it.