The data we need
from you

Once your data flows, the platform tells you every morning which stores are about to run out, which are sitting on stock they will not sell, how much to order from each vendor and when, and which units to move between locations. The numbers are already calculated when you log in. Your team’s job is to approve, edit or reject them.

To do that we need a small, fixed set of files from your systems. Nothing here is exotic — every item is a report your ERP can already produce. The work is agreeing the exact columns once, then scheduling the export.

The honest part

Everything the platform says is built from these files, so the quality of your files is the ceiling on the quality of your answers. If your stock position is a day old, we will confidently send units to a store that took delivery last night. If your vendor lead times are wrong by two weeks, every order we recommend is placed two weeks late. We tell you when a file looks unlike your normal volume, but we cannot invent data you did not send.

What we do not need

This list usually shortens a data protection review considerably. We ask for none of the following, and we refuse it if it turns up in a file:

• No customer personal data. No names, addresses, phone numbers, email addresses, loyalty IDs or dates of birth. We plan stock, not people.
• No basket or receipt-level sales. We take units and value totalled by week, size and store. We never see an individual transaction.
• No payment data. No card numbers, no tokens, no bank details.
• No employee data. No staff rosters, no performance figures.
• No free-text fields from your systems that might contain any of the above. If your export carries a comments column, drop it.

The only personal data in the platform is the name and work email address of your own staff who log in, which we need in order to show who approved which order. There is no special category data and no profiling of individuals anywhere in the system. Security and data protection covers the rest of what your security team will ask for.

This is the table to forward to your ERP team. The first eleven rows are the hard requirement for go-live; the rest make the answers better and can follow afterwards.

Column-by-column definitions for every file above — types, allowed values, which columns are required — are in File specifications. Send your ERP developer there once the shape of the project is agreed.

Working out of order wastes effort: we cannot load a single sales row until the products and stores named in it exist. The effort figures below are what this actually takes, not what we hope it takes.

How much sales history to send

More history lets the forecast tell a seasonal shape apart from a trend. With one year we see each week of the calendar once, so “October is always strong” and “this is selling better every week” look identical. With two years we can separate them.

Beyond three years the value falls away for footwear: assortments turn over, and week 40 of four years ago is a different product. If two years is painful but one is easy, send one year and go live, then backfill the second later. A backfill loads at any time and nothing has to be rebuilt around it.

The cutoff

Your files must be complete by 02:00 in your own time zone. We agree that time with you at kickoff and can move it to suit your nightly close — but it moves for all files together, not for one file.

Those times are the latest, not the plan. If everything lands before 02:00 we do not wait — the calculation starts as soon as the day’s files are complete and verified, so an early sender gets an early dashboard.

If a file is late or missing

We do not run yesterday’s numbers through today’s engine. Allocating from a day-old stock position sends units to stores that already received them, and that mistake is expensive and slow to unwind. So if the inventory file is missing at the hard cutoff:

• The platform keeps showing yesterday’s published results, with a banner on screen saying so. Nothing silently pretends to be current.
• No new allocation plans are created. Anything approved yesterday still ships. Today’s replenishment simply does not exist.
• No new order recommendations. If today was your order-cut day for a vendor, that order slips a day or a buyer places it by hand.
• Alerts and KPIs do not move. A store that went out of stock last night is not flagged until the data arrives.
• We email your named data contact within 15 minutes of the hard cutoff, and again at 07:00.

If the file lands by 09:00 we run a catch-up and the platform is current before lunch. Later than that and you have effectively lost a planning day.

These files change slowly. Most teams schedule the weekly ones alongside the daily job and send the rest by hand when something changes — a refit, a new store group, a renegotiated lead time.

Empty is not the same as zero

They mean different things and we treat them differently. 0 means “the value is zero” — an on-hand of 0 means that store is out of stock. An empty field means “we do not know, or it does not apply”.

• On hand, in transit and on order in the inventory file must never be empty. Send 0.
• An empty cost or retail price is fine. We treat the product as having no known cost rather than a cost of zero, which would make every margin look perfect.
• Never send the text NULL, NA, N/A, - or #N/A. Send nothing at all.

Leading zeros — the trap that catches almost everyone

How to avoid it, in order of preference:

1. Never open the file in a spreadsheet. Export straight from your ERP, your SQL client or your BI tool to CSV and send it. A spreadsheet is not part of the pipeline.
2. If a human has to review it, open a copy and never save over the original.
3. If you must build the file by hand, import with Data → From Text/CSV and set every code column to type Text before loading.

We check for this. If the store codes in your file are all plain numbers but the codes in your store list carry leading zeros, we reject the file and tell you what probably happened — rather than quietly loading 90% of it.

Naming your files

<feed_name>_<YYYYMMDD>.csv
<feed_name>_<YYYYMMDD>.csv.gz
<feed_name>_<YYYYMMDD>_p<NN>of<NN>.csv.gz     a large file split into parts
<feed_name>_<YYYYMMDD>_r<N>.csv.gz            a correction to a file already sent

The date in the name is the business date the data describes, not the date you happened to send it. A file generated at 01:30 on 2 August holding the position at close of business on 1 August is named for 1 August.

Telling us the drop is finished

When the last file of the night has uploaded, write one small completion file (manifest) listing what you sent and how many rows each file held. It is about ten lines in your export script and it is the most valuable thing you can give us: a file truncated halfway through your export is still perfectly valid CSV and will still load, so the row count is the only thing that catches it.

{ "business_date": "2026-08-01",
  "is_complete": true,
  "files": [ { "feed_type": "inventory_position",
               "key": "inventory_position_20260801.csv.gz",
               "row_count": 2140882, "mode": "full" } ] }

Row counts exclude the header and have to match exactly. Mode is full for a complete population, delta for changes only, or restate when the file replaces a window of dates outright. If your export tooling genuinely cannot produce a completion file, tell us at kickoff and we will run your workspace on the clock instead, taking whatever has arrived by the hard cutoff — it simply cannot catch a truncated file. The full field list, including the checksum and byte count, is in File specifications.

Every option lands in the same place: a private folder that only you can write to. No other client can see it and your files cannot be mixed with anyone else’s. Files are encrypted, every version you send is kept, and we can hand back the exact bytes you sent us at any point.

The recommended route, in a little more detail

You get a private folder with one sub-folder per feed. Your nightly job writes the data files, then the completion file, and stops:

<your-workspace>/inbox/inventory_position/<upload-id>/inventory_position_20260801.csv.gz

The upload id is any unique value your script generates per file. It exists so that re-sending a file never overwrites the earlier one, which is what lets either side prove later exactly what was sent and when.

• Access is scoped to your workspace and to the feeds you have agreed to send. It reaches nothing else, and it is issued and revoked by us rather than shared as a long-lived secret.
• Your delivery folder accepts files; it is not a place to browse. Confirmations, error reports and results come back through your results folder instead — section 08 of the data flow guide covers what you can read back.
• A correction is a new file, never an edit of an old one. Use an _r1 suffix. Processed files are cleared from your inbox on the schedule set out in your contract.

What happens to a file the moment it lands — the checks, the receipt your job can poll, the error report with row numbers, and the status screen — is covered in How your data flows.

We do not have inventory at size level, only at style-colour. Can we still use this?

Yes, with one honest caveat. Send the inventory file with a single “one size” entry per style-colour and everything runs at style-colour level — statuses, orders and transfers all work. What you lose is size-level allocation, which is where most of the value sits in footwear: knowing you have forty pairs of 994257 “Trailblazer Runner White/Frost” but none in a US 8 or 9 is the difference between a healthy store and a dead one. If your warehouse system knows sizes even though your store system does not, send warehouse rows at size level and store rows at style-colour level. We handle the mix, and we can estimate the store size mix from sales.

Our fiscal week starts on Monday, not Saturday.

Fine — it is a setting, not an assumption. Send your calendar with whatever weeks you use, including 53-week years and any shifted weeks, and every weekly number in the platform follows it. We never derive weeks ourselves, which is exactly why the calendar is the first file we ask for.

We have two ERP systems — one came with an acquisition.

Common, and workable. Either you merge before sending — one file per feed, with codes made unique across both systems — or you send from each system separately and we merge on load. We prefer the second, because then we can tell you which system a suspect number came from. Either way the one rule is that a code cannot mean two different things. If store 0115 exists in both systems as two different shops, one has to be renamed before go-live. In a two-system onboarding that is usually the single biggest task — budget three days for it.

What if a store opens mid-season?

Tell us before it opens. Add it to the store file with a status of Pending and its opening date, and we start planning stock into it in time for the doors opening. Because it has no history of its own, its forecast comes from a sister store you nominate as similar — and you can nominate a different one per product group, so a new mall store can borrow one comparison for footwear and another for accessories. After about eight weeks of its own sales we switch to its own history automatically.

Our product codes changed last year. The history is under the old codes.

Normal, and we handle it — but it needs one thing from you: a two-column mapping of old code to new code. We restate the history onto the new codes so the forecast sees one continuous series instead of two half-length ones. Without a mapping, every product looks brand new for its first season, and the forecast is measurably worse for that season.

Can you pull the data from us instead of us pushing it?

Yes. We can read from an SFTP server or a cloud folder you own, on a schedule, and it adds roughly a week to onboarding. We recommend against it for one reason: pulling means guessing when your data is final. If you do go this way, have your job write a small marker file last, and we will wait for it before reading anything.

We restate sales after the week closes — returns, corrections, late store uploads.

Expected, and handled. Send the corrected weeks again in any daily file and the new numbers replace the old ones for that week, size and store. You do not need to tell us what changed. We suggest resending the last four weeks every day as a matter of course: it is cheap, and it makes the “our numbers do not match yours” conversation disappear.

Some of our stores are franchises and we cannot see their stock.

Send them in the store file so they exist and their sales count, but leave them out of the inventory file. They show as having no position and we do not generate replenishment for them. If franchisees send you a weekly stock declaration, put it in the same inventory file — weekly data is far better than none, and we show its age on screen rather than pretending it is current.

What happens if we send the same file twice by accident?

Nothing bad, and that is deliberate. Identical content is recognised and ignored. If the content differs — because your job re-ran and picked up more rows — the newer file replaces the earlier load for the rows it contains. Your export job does not need to be clever about this.

Can we add or change a column later?

Adding one is free: send it, tell us, and we start using it. Removing or renaming one needs 30 days’ notice so we can switch cleanly, and we give you the same notice in return. The one thing to avoid is changing the meaning of a column silently — if net sales starts including tax one Monday, every trend in the platform breaks and it takes days to work out why.

1. 1
   Before anything else

   • Kickoff call held.
   • Named technical owner and named merchandising owner agreed on your side.
   • Escalation contact and phone number for data failures agreed.
   • Transport option chosen, and access confirmed working with a test file.
   • Time zone, daily cutoff time and reporting currency confirmed.
   • Recipients of the daily confirmation email agreed — we suggest one from IT and one from merchandising.
2. 2
   Week 1 — foundations

   • fiscal_calendar — three years back, two forward, with your week start day confirmed.
   • store — every store, including closed ones.
   • dc — every warehouse.
   • Store and warehouse codes checked for leading zeros before the first send.
3. 3
   Week 2 — products and history

   • product_style_color and product_sku — the full list, with a sort order on sizes so US 10 does not appear before US 7.
   • Product hierarchy confirmed: division, department, class, subclass.
   • sales_weekly backfill — target 104 weeks, minimum 52.
   • Bad or excluded date ranges in the history declared.
   • Old-code to new-code mapping supplied, if your codes ever changed.
   • First inventory_position snapshot loaded and reconciled against your own stock report.
4. 4
   Week 3 — the supply side

   • purchase_order — open lines plus the last 30 days received.
   • vendor and vendor_style_terms — lead time, minimum order quantity, pack size, order multiple.
   • store_dc_mapping — including transit days door to door.
   • product_dc_mapping.
5. 5
   Week 4 — the merchandising decisions

   • price_promo — 52 weeks back, 8 to 13 weeks forward.
   • product_status_period and store_status_period.
   • store_group — the groups you actually plan against.
   • product_store_eligibility — your assortment matrix.
   • Sister stores nominated for any store opening in the next six months.
6. 6
   Week 5 onward — automation and go-live

   • Daily export job scheduled and running unattended.
   • Completion file written last, with a row count for every file.
   • A failed export pages your team, not only ours.
   • Daily confirmation email arriving and being read by a human.
   • Two clean weeks of daily files with no rejections.
   • Parallel run reviewed with merchandising, then go-live sign-off.