com.yaktool/store

Convert a product export between Shopify and WooCommerce, applying 21 documented rules. This is a STRUCTURAL conversion, not a column rename — renaming columns loses variants and every sale price. What it reshapes: Shopify handle groups become a WooCommerce variable product plus variation rows linked through Parent (and back again); per-image rows collapse into one comma-separated Images cell (and expand again); Option1/2/3 become Attribute N name/value(s). The critical value fix: the two platforms store sale prices in OPPOSITE columns. Shopify Variant Price is the current price and Compare At is the crossed-out one; WooCommerce Regular price is the crossed-out one and Sale price the current. A naive mapping silently erases every discount in the catalogue. Also translated: grams to the store weight unit, TRUE/FALSE to 1/0, Status active/draft/archived to Published 1/-1/0 (archived becomes private — a conversion never deletes), inventory policy to backorders, taxable to tax status, barcodes into the GTIN column. It never invents data: columns with no equivalent in the target platform (vendor, SEO fields, cost per item, per-market prices, categories) are returned in droppedColumns WITH REASONS instead of being written into an approximately similar column. Direction is detected from the header row; pass `direction` only when the file is not recognisable. Returns { direction, directionSource, csv (the converted file), header[], transforms[{ruleId, label, count, example}], droppedColumns[{name, reason, ruleId}], findings[], summary{sourceRows, outputRows, simpleProducts, variableProducts, variations, ...} }. Read transforms[].example to verify each translation on real values, and droppedColumns before telling anyone the migration is complete.

Pre-flight a WooCommerce product CSV against 40 documented rules and forecast what the import will actually do. WooCommerce fails quietly in two ways this catches: (1) a row whose SKU or ID already exists is SKIPPED unless "Update existing products" is ticked — the run still reports success; (2) any column the importer does not recognise defaults to "Do not import" on the mapping screen, so its data never arrives and nothing warns. Because the outcome depends on a checkbox the user has not ticked yet, the result gives BOTH forecasts side by side (summary.addMode and summary.updateMode) rather than guessing one. Pass `existingSkus` / `existingIds` (from Products → Export) to turn the skipped/updated split from an assumption into a fact — without them every row is forecast as new. Also checks: required Name column, duplicate SKUs, product types and variation Parent references (which need the "id:123" prefix for IDs), attribute name/value pairing, Published 1/0/-1/2, booleans that must be 1/0, plain-number prices, YYYY-MM-DD sale dates, stock, category hierarchy with ">", image URLs, FULL GS1 validation of the GTIN column, plus delimiter, UTF-8 damage, invisible characters and spreadsheet damage. Returns { rows[{line, sku, id, type, name, addMode, updateMode, findings[], ok}], columns[{name, mapped, note?}], fileFindings[], summary{addMode, updateMode, unmappedColumns, errorRows, byRule, delimiter, hasStoreContext, ...} }. Read summary.addMode.skip and summary.unmappedColumns first — those are the two silent failures.