DEV Community: 王磊

Parsing multi-gigabyte Outlook PST files in the browser

王磊 — Fri, 14 Aug 2026 01:30:36 +0000

Disclosure up front: I build Mailward, a browser-based PST/OST/OLM/MBOX/EML viewer. These are the implementation notes.

A PST file is not a folder of emails. It is a single-file B-tree database — Microsoft documents the layout as [MS-PST] — and the mail inside exists only as sets of typed properties. To show one message you walk the B-trees, resolve the property set, and reconstruct an RFC 5322 message from scratch.

Now do that in a browser tab, for a 4 GB file, without uploading it anywhere and without loading it into memory.

The constraint that shapes everything

The whole point of a browser-side viewer is privacy: the file never leaves the machine. That rules out "stream it to a server". And FileReader.readAsArrayBuffer on the whole file rules itself out the moment archives pass a gigabyte — mobile Safari will simply kill the tab.

So the parser must do random access over a File it never fully reads.

One method to intercept

We build on pst-extractor, a faithful JS port of java-libpst. It has one architectural gift: every byte it reads funnels through a single method, PSTFile.readSync(buffer, length, position).

That means you can subclass PSTFile and reroute all I/O without touching parser internals:

import { PSTFile } from "pst-extractor";

let pendingReader: RandomAccessReader | null = null;

class ReaderBackedPSTFile extends PSTFile {
  archiveReader!: RandomAccessReader;

  constructor(reader: RandomAccessReader) {
    pendingReader = reader; // super() reads the 514-byte header via readSync
    try {
      super(Buffer.alloc(0));
    } finally {
      pendingReader = null;
    }
    this.archiveReader = reader;
  }
}

(ReaderBackedPSTFile.prototype as any).readSync = function (
  buffer: Buffer, length: number, position: number
): number {
  return (this.archiveReader ?? pendingReader).read(buffer, length, position);
};

Two quirks worth explaining:

The override lives on the prototype, outside the class body, because PSTFile's constructor immediately reads the 514-byte header — so the replacement must already be installed while super() runs.
Instance fields don't exist yet at that point, hence the module-scoped pendingReader handoff. Workers are single-threaded, so this is safe.

The reader: 64 KB pages, LRU-capped

RandomAccessReader is a paged view of the file:

64 KB pages, loaded on demand.
LRU cache capped at 1024 pages — 64 MB worst case, regardless of file size.
Reads that span page boundaries are assembled from multiple pages.

Inside a Web Worker the page loader is almost embarrassingly small, because FileReaderSync gives you synchronous random access to a user-selected File:

class FileSlicePageLoader {
  private reader = new FileReaderSync();
  constructor(private file: Blob) {}

  loadPage(start: number, length: number): Uint8Array {
    return new Uint8Array(
      this.reader.readAsArrayBuffer(this.file.slice(start, start + length))
    );
  }
}

file.slice() doesn't copy — it's a view. We measured a 4 KB slice read at ~200 µs in Chrome, which makes B-tree walks feel instant. The same RandomAccessReader interface is backed by a plain Buffer in Node, so the entire parser is testable outside the browser.

If you're in Node, you don't need any of this

pst-extractor's constructor accepts either a Buffer or a filename. The 2 GB failures people report almost always come from fs.readFileSync → Buffer. Pass the path instead and the library reads through a file descriptor with no Buffer ceiling:

const pst = new PSTFile("/path/to/large.pst"); // descriptor-backed

What this doesn't solve

Honesty section: none of this repairs a corrupted PST — if scanpst can't open it, a reader can't either. And ANSI-era PSTs (Outlook 97–2002, the 2 GB-capped variant) parse through the same pipeline in theory, but genuine ANSI files written by 20-year-old Outlook are nearly impossible to test against, so we claim "likely works, fails loudly" rather than "supported".

More format field notes (OST's account lock, OLM's timezone-less UTC timestamps, MBOX From-munging) live in this repo: email-archive-formats.

Shopify Markets CSV Price Updates: A Safer Way to Verify Catalog Imports

王磊 — Wed, 05 Aug 2026 01:40:32 +0000

A Shopify CSV import can finish without an obvious error and still leave a market catalog with the wrong price or fewer variants than the base catalog.

This is especially easy to miss after the change from Markets to Catalogs. A product import CSV and a catalog-specific price CSV may look similar, but they are not interchangeable workflows. The safest approach is to treat a market-price update as a small data-reconciliation job.

Why a successful import is not proof

There are three separate questions:

Did Shopify parse the CSV?
Did the intended Handle/SKU rows match the right variants?
Did the target catalog apply the expected price and inclusion state?

The first answer can be "yes" while the second or third is "no." A catalog can fall back to a base price, omit a variant, or keep an old inclusion value without producing the kind of row-level error merchants expect.

A safer workflow

1. Save a baseline

Export the current product state and record the target market/catalog, export date, currency, and number of products and variants. Keep this as a rollback reference. Do not start by editing the only copy of the export.

2. Use the target catalog's own template

Open the specific catalog you intend to update and download its sample or export format when Shopify provides one. Do not assume that columns such as Price / US, Price / UK, or Included / US belong in the ordinary product import flow.

For a catalog-specific file, keep the smallest set of columns that the template documents. In many workflows that means an identity pair plus the catalog fields, for example:

Example columns: Handle, SKU, Price, Included.

Example row: blue-shirt, BLUE-S, 29.90, true.

Use your actual exported headers and identifiers; the example is only a shape, not a universal Shopify template.

3. Normalize numbers before checking catalog behavior

Prices should be numeric and consistent:

Use a decimal point, not a locale comma, unless the target template explicitly says otherwise.
Remove currency symbols and thousands separators.
Keep one currency per file and confirm the catalog currency before importing.
Check for formulas that exported as blank strings or text.
Make sure the same SKU is not repeated for two different variant rows unless that is intentional.

A browser-side numeric price-format check can catch malformed price cells before they create noise in the catalog test. It cannot prove that Shopify mapped a row to the correct market catalog, so treat it as the formatting step only.

4. Compare identities and counts

Before importing, compare the Handles and SKUs in the proposed file with the baseline export. Record:

total rows in the proposed file;
unique Handle + SKU pairs;
missing identifiers;
duplicate identity pairs;
products with fewer or more variant rows than expected.

This catches a common false positive: the file is valid, but the catalog receives only part of the intended variant set.

5. Test a small, multi-variant sample

Choose a few products that cover the risky cases: one single-variant product, one product with several options, one sale-price change, and one product that should be excluded from the target catalog.

After the import, check the catalog itself. Do not rely only on the import toast or the product page's base price.

6. Verify the result in the target catalog

For each sample, confirm the market price, currency display, included/excluded state, and variant count. Then compare the post-import export with the baseline. If one market shows fewer variants or the base price appears in place of the market price, stop the full rollout and isolate that catalog's template and identity rules.

7. Keep a rollback path

Store the original export, the exact file you imported, a short change summary, and the post-import verification result. For a large catalog, keep an exception sheet rather than repeatedly re-importing the whole file while guessing.

The practical boundary

A general CSV validator can help with headers, encoding, row identity, file size, and numeric price formatting. It cannot read Shopify's private catalog state or guarantee that an import changed every market correctly.

That boundary matters: "CSV accepted" is an input check; "catalog prices and variant coverage match the plan" is a post-import reconciliation check. Keeping those two claims separate makes international price updates much safer.

Bulk Update Shopify Product Descriptions and Images Without Blank Overwrites

王磊 — Mon, 03 Aug 2026 01:39:47 +0000

Bulk catalog edits are easy to start and surprisingly easy to make dangerous.

If you need to update hundreds of Shopify product descriptions and replace images, the safest workflow is usually a small, intentional CSV update—not a full export with every column left in place.

1. Start with a fresh Shopify export

Export the products immediately before preparing the change. Keep that original file untouched as your rollback reference. Do not build a new file from memory: the export contains the exact Handles, option rows, and variant structure Shopify currently knows.

For a description-only change, identify the columns you actually need:

Handle
Title
Body (HTML)

If you are changing prices, SKUs, inventory, or variant options at the same time, treat that as a separate change set. Mixing unrelated edits makes it much harder to explain a partial import or recover from an overwrite.

2. Generate the repeated description in a spreadsheet

A spreadsheet formula is enough when the template is stable. For example, if the product title is in column B, a Google Sheets formula can build a simple HTML description:

="<p><strong>"&B2&"</strong> is handcrafted and ships free in 2 days. 30-day returns on every "&B2&".</p>"

Adjust the wording for your store, fill the formula down, then copy the result and paste it back as values into Body (HTML). Values-only paste prevents a later formula change from silently changing the import file.

Keep the original Title column while you work. It is useful for reviewing the generated text, even though the description is the field you intend to update.

3. Avoid the blank-column trap

For an existing-product update, an omitted column and an included blank column do not mean the same thing. A blank column can clear existing data, while an omitted column leaves that field alone.

Before importing, remove every column you are not deliberately updating. Preserve all variant rows for each Handle if your file still contains variant-level fields. Never sort rows in a way that breaks the product's Handle grouping, and never remove option columns from a variant update without first checking how Shopify will match the variants.

4. Treat images as a separate decision

A Shopify product CSV carries image references, not files sitting on your laptop. If new images are already hosted, use direct public https:// URLs in Image Src and keep the Handle and image position mapping consistent. If the files are local, upload them to a location that produces stable public URLs before importing.

Do not mix a large image replacement with a description update unless you have a clear reason. A description-only pilot is easier to verify, and an image-only pilot makes URL or row-mapping failures much easier to isolate.

5. Pilot before the full catalog

Import one or two representative products first. Confirm the description, variant count, image order, and unchanged fields in Shopify admin. Keep the pre-import export and the exact CSV you uploaded.

After the pilot, export the affected products again and compare the before/after values. Only then expand to the rest of the catalog. If the catalog is large, split the work into batches that each have a clear product range and a simple rollback point.

For a faster preflight of identity matching, changed columns, blank overwrites, and update-only risk, I use this browser-side Shopify existing-product CSV update audit. It does not import into Shopify or replace the pilot; it helps make the file's intended change set visible before you upload it.

A Safer Way to Bulk-Update Shopify Product Descriptions by CSV

王磊 — Sat, 01 Aug 2026 01:39:09 +0000

Bulk-editing 200 Shopify product descriptions sounds like a spreadsheet task. It is, but the dangerous part is usually not the formula. It is sending a full export back to Shopify with columns you did not intend to change.

A safer workflow separates content generation, import scope, and post-import verification.

1. Start with a dated baseline

Export the products before making edits and keep that file unchanged. Treat it as the rollback reference, not as the file you will immediately import.

Record which products are in scope and keep the export date in the filename. If an app or another team member changes the catalog while you work, the baseline can become stale, so re-export before a large production update when possible.

2. Generate descriptions in a separate column

In Excel or Google Sheets, build the new Body (HTML) value from the existing Title column and your approved template. Review a few short, long, and unusual titles manually before filling the formula down.

Keep the original description in a separate working column until the new text has been reviewed. Do not paste spreadsheet formulas into Shopify; paste values into Body (HTML) after the formula is checked.

This is also the point to decide whether HTML is really needed. Unescaped quotes, copied rich text, and spreadsheet formatting can create a description that looks acceptable in the sheet but behaves differently after import.

3. Trim the import file

For a description-only update, the file should normally contain only the stable identifier and the fields you intentionally changed:

Handle
Title, if you are using it for review
Body (HTML)

An included blank cell can clear an existing value. A column that is absent is different: Shopify cannot update what you did not include. Remove unused price, inventory, option, image, and metafield columns instead of leaving them blank.

If you are changing variants, keep the relevant option and identity columns together and test one multi-variant product first. A description update should not accidentally become a variant update.

4. Treat images as a separate job

A product CSV carries image URLs; it does not upload image files from your computer. For new images, prepare stable public URLs first, then review Image Src, Image Position, and the repeated Handle rows together.

Check that each URL is reachable and that the image order is intentional. Do not assume a reachable URL proves that Shopify will associate every Variant Image reference correctly. If the images are only local files, upload them through an appropriate Shopify workflow before preparing the CSV.

5. Run a preflight before production

Use a small representative batch first, then compare the exported result with the baseline. Look specifically for changed Handles, missing variant rows, unexpected blank cells, and fields that changed outside the requested description scope.

A browser-side checker such as the Shopify CSV Existing Product Update Audit can flag missing identifiers and risky blank cells, then produce a smaller update file for manual review: https://shopify-csv.aivismonitor.com/shopify-csv-existing-product-update-audit

The checker does not write to Shopify or guarantee a rollback. That boundary is useful: the merchant still decides which rows to import and verifies the result.

6. Verify after import

Open a few updated products and confirm the rendered description, HTML structure, image count, image order, options, and variant identities. Compare a fresh export with the pre-import baseline. If anything outside the intended fields changed, stop the next batch and investigate before continuing.

The repeatable rule is simple: generate in a working sheet, import the smallest intentional file, and verify the exported result before scaling up.

Shopify CSV Cost per Item: Audit It Before You Create a Purchase Order

王磊 — Thu, 30 Jul 2026 01:41:57 +0000

A native Shopify Purchase Order can leave line-item costs blank even when a variant already has a Cost per item value. That is a workflow gap, not necessarily a bad CSV.

A CSV can still help you prepare the numbers safely, but it cannot reach into a native Purchase Order and fill its lines. Treat the CSV step as a controlled cost review before you create or receive the PO.

1. Start with a fresh product export

Keep the original export unchanged. Work from a copy that includes the fields you need to identify each variant and compare the economics:

Handle
Title
Variant SKU
Variant Price
Cost per item

If your catalog uses barcodes or another stable identity, keep that reference too. Do not delete the baseline: it is the evidence you need if a later import changes more rows than intended.

2. Check identity before checking the numbers

A cost value is only useful when it is attached to the right variant. Before reviewing costs:

Look for blank or repeated identifiers.
Confirm that the SKU or other identity maps to one intended variant.
Keep option values when several variants share a product Handle.
Separate a supplier SKU from Shopify's own Variant SKU instead of silently treating them as interchangeable.

This prevents a clean-looking cost column from being applied to the wrong size, color, or pack.

3. Review Cost per item beside Variant Price

For each variant, check:

Cost per item is present and numeric.
Variant Price is present and numeric.
Cost is lower than price when a sale is expected to be profitable.
A blank, zero, or unusually large value is reviewed instead of being accepted automatically.
A supplier cost increase does not quietly turn a previously healthy margin into a loss.

The Shopify product CSV margin audit can calculate the margin amount and percentage locally from those columns and surface missing cost, invalid price, and low-margin rows for review.

4. Separate standing cost from the PO cost

Cost per item is a product-level reference. A Purchase Order is a specific supplier agreement at a specific time. If two suppliers quote different prices, keep the agreed PO cost in your purchasing worksheet and decide deliberately whether the standing product cost should change.

A practical worksheet can include:

Supplier and supplier SKU
Shopify Variant SKU
Ordered quantity and location
Agreed unit cost and currency
Freight, duty, or other adjustments
The date and reason for any standing-cost change

This preserves the historical price you actually agreed to instead of rewriting it later when a supplier sends a new list.

5. Test the smallest safe change

If you need to update product costs through Shopify's CSV workflow, use one representative product or a very small variant batch first. Compare the result with the original export, then expand only after the identifiers and cost values are confirmed.

Do not assume that a successful product CSV import means the native Purchase Order was populated. Verify the PO lines separately in Shopify and record any manual cost entry that remains.

What this workflow does not do

A browser-side CSV review cannot access a merchant's admin, read native Purchase Orders, call the Admin API, or write costs back automatically. It prepares evidence and a safer review path; the final Shopify import and PO entry remain manual actions.

That boundary is useful: it keeps supplier and store data local, makes the cost decision explicit, and avoids presenting a worksheet as an integration that Shopify does not expose.

Shopify CSV Files Over 15MB: Split by Product Handle, Not Row Count

王磊 — Tue, 28 Jul 2026 01:40:08 +0000

When a Shopify product CSV grows past 15 MB, making it smaller is only half the job. The split must keep each product together, or Shopify may receive variants and image rows without the parent context they need.

A safer batching checklist

Keep the untouched Shopify export as your rollback reference. Make a working copy before removing or reordering anything.
Group rows by the exact Handle. Do not split after an arbitrary line number: one product can occupy several rows.
Keep every variant row for a Handle in the same batch. Check Option values, Variant SKU, price, inventory, and barcode together.
Keep the product's image rows with the same Handle. Moving an Image Src row into another file can attach media to the wrong product or make the import harder to audit.
Check each batch independently for headers, UTF-8 text, prices, and duplicate Handles before importing.
Import a small representative batch first. Confirm product count, variant count, prices, inventory, and images before continuing with the remaining files.
Keep a simple batch log: file name, Handle range, row count, import time, and any Shopify warning. This makes a partial retry much safer.

The 15 MB limit is a file-size boundary, not a promise that a large catalog will import cleanly. Long descriptions and image URLs can push a file over the limit, while a row-count split can quietly break variant groups. A handle-aware split plus a post-import spot check gives you a better audit trail.

For a browser-side check and handle-aware batching guide, see the Shopify CSV size checker. It prepares review guidance locally; it does not upload files to Shopify or change products in your admin.

Shopify CSV Prices That Look Right but Still Fail: A Pre-Import Checklist

王磊 — Sat, 25 Jul 2026 01:43:09 +0000

A Shopify CSV can look perfectly normal in a spreadsheet and still fail, skip values, or change the wrong variants after import. Price columns are a common reason: spreadsheet locale settings, currency symbols, thousands separators, and variant-row matching can all change what Shopify receives.

Here is a practical pre-import checklist.

1. Start from a Shopify export

Use a recent product export as your baseline. Keep the original file untouched, then make a working copy for edits. Confirm that the file uses Shopify's expected headers, especially Handle, Option1 Value, Variant SKU, Variant Price, and, when relevant, Variant Compare At Price.

Do not rebuild a large catalog from a blank spreadsheet unless you have a strong reason. The export preserves the row structure that Shopify uses to group products and variants.

2. Make the price format unambiguous

Before saving the CSV, check that:

prices use a decimal point, not a locale-specific decimal comma;
currency symbols are not embedded in the cell value;
thousands separators are not left in values such as 1,299.00 unless your cleaning step removes them safely;
empty cells are intentional, especially on continuation rows;
compare-at prices are reviewed together with the selling price.

If the spreadsheet displays a value as currency, inspect the raw cell value before exporting. A display format can hide characters that end up in the CSV.

3. Verify variant identity before changing prices

A correct price on the wrong variant is still a bad import. For each product, check that:

every variant row keeps the same Handle;
option names and values stay paired;
SKU or another stable identifier matches the baseline export;
the update file does not accidentally include blank columns that could overwrite existing data;
the number of variant rows is unchanged unless you intentionally add or remove variants.

For a large catalog, test one representative product with multiple options before preparing the full file.

4. Scan the working copy

Run the working CSV through a local checker and review critical findings before exporting a cleaned copy. Pay special attention to malformed prices, unexpected headers, encoding warnings, duplicate handles, and file-size warnings. Treat the report as a preflight review; it cannot know whether a particular sale price is commercially correct.

For a quick browser-side check, use the Shopify CSV price format fixer to review price cells and export a cleaned copy when the correction is unambiguous.

5. Import a tiny batch and compare

Import a small set of products first. After Shopify finishes, compare the result against the baseline:

selling price and compare-at price;
variant SKU and option values;
inventory policy and availability;
product count and handle count.

If the result differs from the plan, stop before uploading the full catalog. Keep the original export and the tested CSV so you can explain exactly what changed.

Final caution

A CSV preflight does not replace Shopify's importer, change market-specific pricing, or guarantee that a theme or app will display prices as expected. It helps narrow down file-level risks so the next import is easier to verify.

From Supplier PDF to Shopify CSV: A Safer Staging Checklist

王磊 — Thu, 23 Jul 2026 01:39:55 +0000

Supplier catalogues often arrive as PDFs, while price lists arrive as spreadsheets. The tempting workflow is “give the files to an AI and upload the result.” The safer workflow is to treat this as a data-matching and import-preflight project.

A PDF is a presentation format, not a Shopify product data model. Before any upload, create a reviewable intermediate table and keep a clear line between extracted facts, assumptions, and fields that still need a human decision.

1. Choose one stable identity

Pick the supplier SKU or product code as the primary matching key. Keep it as text so spreadsheet software does not turn long codes into scientific notation or remove leading zeroes.

For each row, record:

supplier SKU or product code
product title and a proposed Handle
variant option names and values
price and currency
vendor
image source reference
a short source-page or source-file note

Do not match a price list to a catalogue by title alone. If a code is missing, duplicated, or spelled differently in the two sources, put that row in an exception list instead of guessing.

2. Build variants deliberately

Shopify product CSVs represent one product across multiple rows. Give all variants of the same product the same Handle, keep the option names consistent, and give each distinct variant its own SKU when one exists.

Check for the common failure modes:

one variant accidentally gets a new Handle
a colour or size value changes spelling halfway through the product
a blank or reused SKU makes two variants look identical
an update file contains only one variant from a multi-variant product

Keep a last-known-good product export nearby so you can compare identity before changing existing products.

3. Treat images as a separate mapping

An image printed in a PDF is not automatically a usable Shopify image URL. If you have public image URLs, test that each URL opens directly without a login, redirect chain, or expiring session. Then map the image to the correct product and variant before importing.

Do not silently replace a missing image with a guessed supplier URL. Mark it for review.

4. Validate the structured CSV

Once the table has become a Shopify-shaped CSV, run a local preflight for headers, encoding, prices, handles, variant grouping, image fields, and file size. The browser-only Shopify CSV Import Fixer is useful at this stage because it can flag structural problems before you upload a small test batch.

The checker does not parse supplier PDFs, crawl supplier websites, create products, or write to Shopify. It is a safety net for the structured CSV you have already prepared; ambiguous catalogue decisions still need review.

5. Import in a small batch

Start with a few complete products: include every variant, one or two images, and the fields you actually intend to update. Confirm the preview, import result, handles, prices, option values, and image assignments before expanding the batch.

Keep the original source files, the intermediate mapping sheet, the final CSV, and a short exception report. That trail is much easier to debug than trying to reconstruct why a large catalogue import changed an existing product.

The goal is not “one-click PDF to store.” It is a staged conversion where every uncertain match is visible before Shopify receives the file.

Shopify CSV Variant Updates: Why a Tiny Batch Protects Existing Options

王磊 — Tue, 21 Jul 2026 01:39:40 +0000

A Shopify product CSV can look valid in a spreadsheet and still change more variants than you intended. This is especially easy to miss when you are updating prices, inventory, SKUs, or option values on an existing catalog.

The safest approach is to treat a CSV update as a comparison problem, not just a formatting problem.

1. Keep a last-known-good export

Before editing, save a fresh Shopify product export as the baseline. Keep it unchanged. Your working file should be a separate copy.

At minimum, preserve these identity fields while you work:

Handle
Option1 Name, Option1 Value
Option2 Name, Option2 Value
Option3 Name, Option3 Value
Variant SKU
Variant Barcode

If a row is meant to update an existing variant, its identity should remain recognizable in both files.

2. Check each Handle as a group

Shopify product CSVs represent a product and its variants across multiple rows. Group the file by Handle and compare the variant count with the baseline.

For every product group, look for:

A Handle that was accidentally renamed or blanked.
A populated option value without the matching option name.
A duplicate combination of option values.
A variant that exists in the baseline but disappeared from the working file.
A new row that has no SKU, barcode, or other deliberate identity.

Do not delete a row merely because it looks repetitive. Repeated Handles are normal when one product has multiple variants; the risk is an unintended change to the group structure.

3. Separate formatting fixes from catalog decisions

Normalize obvious formatting issues, but review catalog decisions manually. Prices should use a dot as the decimal separator and should not include currency symbols. Be careful with blank cells in an update file: a blank may be interpreted differently from “leave this field unchanged,” depending on the import workflow.

For a price-only change, keep the option and variant identity columns intact. Avoid rebuilding the whole product row when a smaller update file is enough.

4. Test a small, representative batch

Choose a few products that cover the risky cases: one single-variant product, one product with two options, and one product with several variants. Preview that batch first, then compare:

number of products shown,
number of variants per product,
option names and values,
SKUs and barcodes,
intended price changes only.

If the preview count is surprising, stop before importing the full catalog.

For a browser-side first pass over a Shopify-shaped CSV, the Shopify CSV Variant Error Checker can flag structural issues before you prepare the smaller test batch. It does not write to Shopify, and the final import still requires your review in Shopify admin.

The key checkpoint is simple: export, compare by Handle and variant identity, test a small batch, and only then import the full update.

Before Stocky Goes Read-Only: A Safer CSV Export Checklist

王磊 — Mon, 20 Jul 2026 01:36:45 +0000

Stocky’s shutdown creates a data problem that is easy to underestimate. A clean purchase-order CSV is useful, but it may not preserve the context behind the numbers: supplier notes, receipt dates, partial deliveries, historical costs, lead times, and reorder decisions.

Before August 31, treat the export as an archive project, not just a one-time migration.

1. Export every source while access still works

Save the raw files before transforming anything:

Purchase orders, including draft, confirmed, archived, and unarchived records
Supplier and vendor data
Stock counts, inventory adjustments, and transfer reports
Current costs and any report that contains historical or manually adjusted costs
Receipt details, especially received dates and partial-receipt status

Keep the original JSON or CSV untouched and date-stamped. A flattened worksheet is a working copy, not a replacement for the source export.

2. Check whether the export is complete

If you use an API export, page through the result until no records remain. A single response can look valid while containing only the first page. Keep a simple count of:

Purchase orders exported
Line items exported
Orders by status
Orders with a supplier, SKU, cost, location, and receipt state

Round-number batches are worth investigating. So are missing statuses, missing locations, and a sudden drop in line-item counts.

3. Preserve the fields that CSVs often flatten

For each purchase-order line, keep the PO number, supplier, SKU, title, ordered quantity, received quantity or receipt state, unit cost, location, and status. Store notes and dates in separate columns instead of combining them into one description field.

If an export has no explicit received quantity, do not invent one. Use the available receipt date and item status as evidence, then mark partial or unconfirmed lines for manual review.

4. Build a small truth set

Pick a few known purchase orders:

One fully received order
One partially received order
One with a cost adjustment
One with supplier or PO notes
One with multiple locations, if applicable

Compare those records against the exported worksheet. This catches missing context before you trust the full archive.

5. Keep the handoff reviewable

Before recreating anything in another system, filter for:

Missing SKU, supplier, cost, or location
Ordered quantity greater than received quantity
Missing receipt dates
Duplicate PO numbers or duplicate line identities
Supplier notes or historical-cost fields that did not survive

A local browser-side option is the Stocky purchase-order JSON to CSV exporter. It accepts a JSON export you provide, flattens purchase orders and line items into a review worksheet, and keeps likely pagination, ambiguous receipts, and missing fields visible. It does not call Stocky, ask for credentials, upload the file, or write back to Shopify.

The practical goal is simple: keep the raw export, prove the archive is complete, and only then decide what deserves a new purchase order, transfer, or migration step.

A Safer Shopify Inventory Transfer Worksheet Before Receiving

王磊 — Sat, 18 Jul 2026 01:42:32 +0000

Large Shopify inventory transfers are easiest to troubleshoot before anyone clicks “Receive.”

When a transfer arrives in several deliveries, the receiving screen is only one part of the problem. The harder question is whether the spreadsheet still identifies the right variant, location, and quantity after the shipment was split. A clean receiving checklist prevents a quick workaround from creating a barcode or inventory problem later.

Start with stable identity

Keep at least one stable product identity on every row:

Variant ID when it is available
Shopify SKU
Barcode only when it is a real, existing barcode

Do not replace a real UPC, EAN, or GTIN with a temporary value just to make a screen searchable. If the receiving workflow does not find a variant by SKU, first confirm whether it expects the barcode field, whether the SKU is duplicated, and whether the row belongs to the correct location. A temporary backfill can be useful only when the barcode field is genuinely unused and the change has been tested on a small group.

Make the shipment boundary explicit

A transfer that arrives in three deliveries should not be treated as one unexplained quantity. Add a shipment or receipt reference to your working sheet, then keep these fields together:

Transfer or shipment reference
Source and destination location
Variant ID, SKU, and barcode
Expected quantity
Quantity in this delivery
Remaining quantity
Review note

The sum of the delivery quantities should equal the expected transfer quantity. If it does not, leave the row open for review instead of forcing the remaining amount into the latest shipment.

Separate planning from receiving

A transfer plan answers “how much should move?” Receiving answers “what actually arrived?” They should share the same identifiers, but they should not overwrite one another.

For planning, compare destination stock against a minimum and target level. Cap the suggested transfer by source availability and flag any source shortfall. For receiving, record the delivered quantity and inspect variance against the plan. A planning worksheet can suggest a quantity; it cannot confirm that a carrier delivered it.

Review before applying changes

Before importing or entering anything into Shopify:

Check that every row has a destination location.
Check that SKU and barcode values are not duplicated across unrelated variants.
Confirm that quantities are numeric, non-negative, and expressed in the same unit.
Keep variant rows together when you split a large file.
Test one small product group or shipment before processing the full transfer.
Save the reviewed before-and-after worksheet for reconciliation.

For a browser-side worksheet that calculates suggested quantities from source stock, destination stock, and min/max rules, see the Shopify inventory transfer CSV planner. It creates a local review file; it does not create Shopify transfers, change barcodes, or write inventory through an API.

The safest transfer workflow is deliberately boring: preserve identity, separate shipments, validate quantities, and keep the reviewed file beside the final Shopify receipt record.

A Safer CSV Review for Shopify Inventory Adjustments

王磊 — Thu, 16 Jul 2026 01:38:22 +0000

Shopify’s newer inventory adjustment flow is more explicit about why stock changes. That is useful for reporting, but it also makes a quick “type -3 and move on” workflow easy to misunderstand.

A safer approach is to review the adjustment file before applying changes in the admin.

What to check first

Before changing a quantity, keep these fields together:

SKU or Variant ID
Location
Previous quantity
New quantity
Adjustment reason
Note, operator label, and timestamp when available

The previous and new quantities are more reliable than a bare positive or negative number. They let you calculate the actual delta and spot a row that would increase stock when you intended to remove it.

A practical review sequence

Export a fresh inventory or adjustment report. Keep the original export unchanged so you have a reference copy.
Confirm that every row has a SKU or Variant ID and a location. A quantity without an identifier is not safe to apply.
Compare previous quantity with new quantity. For a removal, the new value should be lower; for a receipt or correction, it should be higher.
Require a reason such as damaged, theft, cycle count, receiving discrepancy, or transfer. Add a short note when the reason alone is not enough context.
Look for non-numeric quantities and duplicate rows. A duplicate adjustment can quietly double the intended change.
Test one known SKU in Shopify first and read the preview. If the preview moves in the wrong direction, stop and fix the source row.

For a browser-side worksheet that calculates the delta, flags missing reasons or quantities, and highlights possible duplicate events, see the Shopify inventory adjustment reason audit.

Apply the reviewed change manually

In Shopify admin, open Products → Inventory, select the Available quantity, and use the adjustment flow for the relevant location and destination. Add the reason that matches the event, then confirm the preview before saving.

The worksheet is a review aid, not an API writer. Keep the exported audit trail with the original report so a later stock-take or accounting review can explain what changed and why.