Case study · Data and spreadsheets
A supplier import held together by scripts was rebuilt, so that a bad file is stopped and explained.
A supplier's daily file had corrupted the catalogue more than once. We built a pipeline that checks every file and holds a bad one with reasons.
- Who
- A distributor with a small operations team and one technical lead, importing a daily product file from its main supplier.
- The problem
- The import was a tangle of scripts and spreadsheet steps. It had corrupted data more than once, and only one person understood it.
- What we did
- Wrote down every stage, rebuilt each as a tested step, and joined them into a pipeline that releases a good file or holds a bad one with reasons.
- The result
- Every daily file is checked, compared with the previous one, and either released for import or held with a report whose counts add up.
- Time
- Six weeks.
What was going on.
Each morning the supplier's product file arrived, and a chain of scripts and manual steps turned it into updates on the company's store. It had grown by accretion: downloading, decoding, reading, category rules, picture checks and publishing lived in different scripts and in one person's head.
It had failed or corrupted data more than once. Each new fault was fixed in one place and broke another. Adding a second supplier meant copying the same fragile steps again.
What we found.
The trouble was not any one script. It was that nowhere in the chain was a bad file stopped and explained. A file with a changed column, a broken character or a thousand missing prices went straight through to the store.
So we started by writing down each stage: what goes in, what comes out, what is checked and what happens to a file or a row that fails. Then we rebuilt each stage as a small tested step, with a set of made-up test files for every kind of fault the company had seen.
The technical detail
The stages are fetch, decode, parse, category mapping, picture checks where the feed has pictures, a comparison with the previous file, and a decision to hold the file with reasons or release it. Each stage has a written specification and tests against made-up files for its kind of fault. A run produces a hold-or-release report whose counts reconcile: rows read equal rows released plus rows held plus rows rejected.
What we did.
How we checked it.
These had to pass before we asked for sign-off.
- For each kind of fault in the agreed test set, the pipeline holds or rejects the file or row, with a reason, and releases the clean files.
- An end-to-end run on the agreed sample produces a report whose counts reconcile.
- The company approved every stage, and its technical lead ran the pipeline from the run book without our help.
What they have now.
The company received the specification, the pipeline code and its tests in a repository it owns, the test files, the report from the sample run, and a run book covering scheduling, alerts and what to do when a file is held. Its technical lead ran the pipeline from the run book alone before the company approved it.
The first real bad file the pipeline held was a delivery with a column moved. It was stopped with a reason before it reached the store.
What we did not do.
- We did not switch the company's live import to the pipeline. That stayed with its team.
- We never held the supplier's credentials or any live access.
- We did not clean or correct product data already in the store.
- This covers one supplier feed and one target import. A second supplier is quoted separately.
The service behind this.
A supplier import you can trust is one that can say no, and say why.
Project
Rebuild a supplier feed pipeline
Replace one fragile supplier-to-store import with a tested pipeline: fetch, check, compare with the last file, then hold or release, with category and image stages if your feed needs them.
From $5,850. The payment schedule is set in the written proposal. Nothing is charged until you have agreed it.
More case studies.
One-off job
Checkout stopped taking orders after an update
Customers could fill a basket but not pay. We found the cause on a copy of the shop, fixed it and proved it with test orders.
Online store · Two days
One-off job
Genuine payment messages were being rejected
Paid customers still showed as unpaid. The company's code was checking the wrong thing. We fixed it without switching the check off.
Software team · Three working days
Project
Hundreds of products flagged in Google's shopping feed
Several problems at once, and every earlier fix had only revealed the next one. We grouped them by cause and worked through them in order.
Online store · Three weeks, mostly waiting for Google to reprocess
Get a price for something like this
You are asking about: Rebuild a supplier feed pipeline.
Sending this is not an order. We check we can help, then agree what is included, safe access and the price in writing before any work. Prefer email? hello@syntheticindustry.ai.