Most ribbon buying relationships still run on email. A buyer sends a spreadsheet, a factory replies with a quotation, somebody retypes the order into a production system, and six weeks later the finished goods arrive in a quantity that is slightly different from the one that was ordered. Nothing about that is unusual, and for a brand placing four orders a year it works perfectly well.
It stops working when order volume rises. Somewhere around a dozen orders a month, or a few dozen active SKUs, the retyping step becomes the bottleneck and the source of the errors, and the people doing it start doing it differently each time. At that point the business case for integrating systems stops being about efficiency and becomes about control: you want a system that knows what was ordered, what was confirmed, what was actually made, and what was shipped, without any of it depending on somebody’s memory.
This guide covers how to set up order and data integration between a brand’s procurement systems and a ribbon OEM manufacturer. It covers what to integrate and what to leave alone, the master SKU table that everything depends on, the written data contract that prevents most disputes before they happen, the three message types that make up a working relationship, how forecast files should and should not be used, and the timeline and effort each option realistically requires. It is written for procurement managers, supply-chain analysts and owners who have been asked to “get the factory onto our system” and want to know what that actually involves.
Integration projects fail for a predictable reason. The technical work is the easy part — sending a file is a solved problem, and a good integrator can have two systems exchanging messages inside a week. The hard part is that two organisations have to agree on what the data means before any of it is transmitted, and that conversation has to happen at a level where somebody from both sides is willing to make a decision rather than pass the question along.
Consider a single order line. On the buyer’s side it might read “SAT-12-PNK — 3,000m — 15mm satin — Pantone 227 C — FOB Xiamen — ship to Rotterdam — carton 20/roll — label: our brand, our SKU code.” On the factory’s side the same line needs to trigger: yarn selection for a specific denier, a dye recipe for a specific shade, a loom setup for a 15mm satin construction at a specific pick density, a slitting operation, a rolling operation at a specified core, a labelling operation referencing the buyer’s artwork, a carton configuration, an export declaration, and an invoice. Each of those steps requires data that may or may not be in the transaction.
Now consider that the buyer’s ERP holds the shade as a Pantone reference, the factory’s system holds it as a dye recipe number, and the link between the two lives in a spreadsheet one of the buyers’s assistants maintains. Everything works perfectly until that person leaves. This is not a hypothetical failure mode; it is the single most common cause of a colour mismatch dispute we see from brands that thought they had a digital supply chain.
The practical consequence is a rule that should guide every integration decision: integrate the master data once, then keep transactions thin. The heavy data — construction, colour recipe, width, decoration method, carton specification, artwork reference — belongs in a master record that both systems reference. The transaction carries the master record’s identifier plus the variable data: quantity, price, delivery date, ship-to. If your order messages are getting longer and longer, you are probably transmitting master data by accident, and you will pay for it in maintenance every time anything changes.
Before choosing a technology, decide what you want the integration to accomplish. Three levels, in increasing order of cost and difficulty.
The buyer sends a file. The factory sends a file back. Nothing runs automatically; a person triggers the exchange and a person reads the response.
This sounds like a modest step, and it is, but it captures most of the available value. The discipline it imposes is the valuable part: a structured file forces you to define your SKU identifiers, your units and your attributes precisely, because there is no field for “as discussed on the call.” For a brand moving from eight orders a month to fifteen, this is usually the correct level and it can be set up in a fortnight.
Files move automatically on a schedule or trigger, but a person still reviews the outgoing order before it is released and the incoming acknowledgement before it is accepted. This is where most mid-sized brand programmes should sit.
The reason is that in ribbon procurement, not every order should be released automatically. A reorder triggered by a system when your forecast was wrong can create a large commitment of capital on a colour you no longer want. The correct level of automation for a reorder depends on the value of the goods and how predictable the demand is, and that is a commercial decision that the integration should leave to a human until you have evidence.
Orders transmit automatically, acknowledgements return automatically, changes and cancellations are handled electronically, and invoices reconcile against goods receipts without manual intervention. This is the right target for a brand with high volume and many factories, or for a factory serving large retail accounts with formal vendor onboarding requirements.
It is also the level at which the data contract matters most, because at this automation level the people who understand the data are no longer in the loop when something is wrong. The system will process an order that contains a width of 12 mm when your programme calls for 15 mm, and it will do so consistently, because that is what it was told.
| Level | Typical effort | Realistic timeline | Best suited to |
|---|---|---|---|
| One: manual file exchange | 2–5 person-days | 2–4 weeks | Under ~12 orders/month, under ~30 SKUs |
| Two: automated transfer with review | 10–20 person-days | 4–8 weeks | 12–60 orders/month, multi-SKU programmes |
| Three: full trading relationship | 30–60 person-days | 6–12 weeks | High volume, multi-factory, formal vendor onboarding |
Two cautions about that table. The effort figures are for both sides combined, and they assume the factory has already some order-management capability; a factory working entirely from email and notebooks will need more. And the timelines are dominated by decision time, not build time. A data contract that takes four weeks to agree is normal, and a project that hits a build deadline in two weeks usually skipped the contract.
If you read one section of this guide carefully, read this one. Every data error that matters in ribbon procurement traces back to the same place: two organisations maintaining two versions of the truth about what a product is.
A workable master SKU table for ribbon needs these fields. The exact set varies by business, but the categories below cover nearly everything that causes trouble.
| Field group | What it holds | Why it matters |
|---|---|---|
| Identity | Buyer SKU code, factory item code, supplier's own reference, barcode / GTIN if used | The single most common source of mismatch. A buyer code and a factory code need a defined mapping, and one authoritative owner. |
| Product definition | Construction type (satin, grosgrain, organza, velvet, jacquard), fibre content, width in mm, thickness, finish, weave description | These determine the line and the setup. If the transaction does not carry them, the factory assumes a standard construction and you get standard construction. |
| Colour | Buyer colour reference, factory dye recipe number, Pantone or TCX reference, tolerance, colour approval status and date | The mapping between the buyer’s reference and the factory’s recipe is the single highest-risk piece of master data in the whole relationship. |
| Decoration | Decoration method, artwork reference and version, print repeat, foil or screen details, position on ribbon | Decoration artwork changes more often than anything else. The version number in the master data prevents running last year’s file. |
| Format | Roll length, core size and type, winding direction, selvedge, carton quantity, gross and net weight | Format differences are invisible on a purchase order and obvious on the loading dock, which is the expensive place to discover them. |
| Commercial | Unit of measure, currency, Incoterm, price basis, validity period, minimum order quantity for the item | Without a unit of measure in the data, “3,000” can mean metres, rolls or dozens depending on the reader. |
| Logistics | Ship-to and bill-to structure, carton marking, packing list format, label content and placement | Directly affects the receiving operation at your warehouse and at your customer’s warehouse. |
| Compliance | Applicable certifications, care labelling requirements, chemical and labelling standards by destination market | Compliance attributes change by market and by season, and they are rarely in the order message. |
Three practices make the difference between a master table that works and one that becomes another source of confusion.
One owner per field. For each field, name the party who is authoritative. Usually the factory owns construction, colour recipe and format because they are the ones producing it; the buyer usually owns commercial terms and artwork. Where ownership is ambiguous, the field will drift. Write the ownership into the data contract, not into an email.
One identifier, never two in the same message. If both a buyer SKU and a factory code are carried in an order line, the receiver must know which one to key on, and the answer will differ between the sales team and the production team. Pick one as the key, carry the other as a reference field, and record the mapping once.
A change history, not a current-state table. Every change to a master record should be dated, attributed and retained, with a stated effective date. The reason is not bureaucracy. When a shade drifts and you need to know which recipe was in force on the day the order was placed, the change history is the only evidence available, and it is what turns a quality dispute into a solvable question.
A data contract is not a technical document. It is a short, plain-language agreement that says what each exchanged field means, who owns it, what format it uses, and what happens when it is wrong. In a good implementation it runs to a handful of pages, written in a table with columns for field name, definition, format, owner, and error handling.
The reason it matters is that disputes about integrated orders are rarely disputes about bytes. They are disputes about meaning. Two systems can exchange a perfect order and still disagree entirely about what was ordered, because one side read “net” as excluding packaging and the other included it, or because one side interprets a delivery date as the arrival date at the buyer's warehouse and the other as the date goods leave the factory.
A workable data contract for ribbon covers nine areas.
State exactly how a product is identified in each message, which identifier is the key, how new items are created, and what happens when an item is discontinued. Include the rule for when a specification change requires a new SKU rather than a version update. This single rule prevents the most common integration failure in all manufacturing: a product whose specification changed silently, so that order history and the product itself no longer describe the same thing.
Ribbon has several natural units — metres, rolls, cartons, dozens — and they do not convert cleanly because roll length varies by width and construction. Define one unit of measure for ordering (metres is the usual answer), define the conversion rules explicitly, and require that every message carries the unit. Never let a quantity field be ambiguous, even once.
State the currency, whether prices are unit or per carton, which Incoterm applies and at which named place, whether the price includes duty, and how long the price is valid. Include the rule for how a price change is communicated — usually as a formal price list version rather than as a message that overrides a price in a system.
Document the ship-to hierarchy, how a third-party or drop-ship destination is expressed, which entity appears on the commercial invoice, and how the factory knows whether goods are being shipped to a distribution centre or directly to a customer.
This is the most consequential field in the whole message and the one most often left undefined. State whether the date is the factory dispatch date, the ex-works date, the on-board date, or the arrival date. Then state whether it is firm, provisional, or estimated. A factory that confirms a date meaning “dispatch” against a buyer expecting “arrival” has introduced a silent four-to-six week gap, and neither side will notice until the goods are late.
Define the standard lead time per product family, whether it is measured from order receipt, from artwork approval, or from deposit receipt, and what happens to the clock when the buyer is late with artwork, colour approval or a deposit. A lead time without a defined starting point is not enforceable, and this is the single most common cause of a delivery dispute being argued rather than resolved.
State that an acknowledgement will be returned within a fixed window — twenty-four hours is a realistic figure for standard ribbon lines — and enumerate what it contains. Include the agreed behaviour when the factory cannot meet the requested date: acknowledge with a proposed alternative, or reject the line, rather than silently returning a shorter date.
Specify what happens when a message fails validation. Agree which side validates, what the error response looks like, whether the message is quarantined or rejected outright, and how the two sides confirm a corrected resend. Critically, state that a rejected message does not start the lead-time clock, and that the clock starts when a valid order is acknowledged.
Name the version of the data contract, who may change it, how changes are communicated and with what notice, and whether a change applies only to messages sent after a stated effective date. Include the rule for what happens to messages in flight during a change. This section is what prevents the scenario where the buyer's system starts sending a new field in March and the factory’s system silently drops it until someone notices in June.
Three message types make up a working trading relationship. Getting these right covers the overwhelming majority of what most buyers actually need, and each is simpler than it sounds.
The order carries the SKU identifier, quantity and unit, the price or a reference to a price list version, the requested delivery date, the ship-to, the buyer’s PO reference, and any order-specific instruction such as a split delivery or a specific carton configuration.
Two design decisions matter here. First, do not put master attributes in the order. If the order carries the full construction, colour and format description, then every specification change requires every transaction to be updated, and historical orders become unreadable. The order should reference the master record. Second, include the buyer’s PO reference, because the factory will quote it back on the packing list and invoice, and you will spend an afternoon of reconciliation otherwise.
Detailed in its own section below. In short: it confirms or rejects each line, states the confirmed quantity, price, delivery date and the production date behind it, and returns the factory’s own order reference.
Changes are harder than orders, because a change after production starts is not a change — it is a cancellation plus a new order, and it costs the factory real money. Define a change window: changes received before artwork approval are free, changes after artwork approval but before production incur a stated cost, and changes after production begins are handled as a cancellation of the remaining quantity plus a new order at potentially different pricing.
The most useful field in the change message is the change type. A quantity change, a date change, a destination change and a specification change have entirely different cost consequences, and a system that treats them all as “update the line” will generate a dispute every time the answer matters.
Advance ship notice. The factory tells you what is leaving, when, how much, on which vessel or flight, and with what documents. Without it, your freight forwarder is guessing, and your receiving operation discovers the discrepancy when the container arrives.
Shipment confirmation. The factory confirms what actually shipped against what was acknowledged: actual quantity, actual carton count, actual gross weight, actual vessel and container number, and the date of loading. This is the message that makes three-way matching possible between the purchase order, the acknowledgement and the invoice, and it is the one most commonly omitted in ribbon relationships.
A confirmed delivery date is worth more than a fast quote. This deserves its own section because the acknowledgement is the hinge of the whole relationship: before it, an order is an intention; after it, it is a plan both sides are working to.
A useful acknowledgement answers seven questions.
Two rules of practice around acknowledgements.
First, agree a fixed clock and hold it. Twenty-four hours for standard lines is realistic for a factory with an order-management system. The clock matters more than the length: it tells you when a silence is a problem rather than a busy afternoon, and it lets you escalate on a rule rather than on a feeling.
Second, track the acknowledgement rate, not just the order rate. The percentage of orders acknowledged within the agreed window is one of the few genuinely useful integration metrics, because it measures the health of the whole upstream process. If it drops below ninety-five per cent for two consecutive weeks, something has degraded — a person is off, a system is failing, or a large order is sitting unacknowledged — and you want to know before the goods are late.
Forecast files are the most useful and most dangerous thing you can send a factory.
They are useful because a factory that can see your demand six months out can reserve loom capacity, pre-buy yarn against expected consumption, schedule dye batches more efficiently and plan labour against a real workload instead of a sequence of surprises. In a business where yarn and dye chemistry lead times are measured in weeks, a factory with even a rough twelve-month forecast genuinely delivers better lead times than one working blind. That is a real, structural advantage, and it is one of the strongest reasons to integrate even if nothing else about your relationship changes.
They are dangerous because a forecast that is not clearly labelled as a forecast will eventually be treated as a commitment by one side. This happens gradually and then suddenly. A factory reads your rolling file, believes the first quarter is firm, books the loom time and buys the yarn. Then you reorder less than the file suggested, because your retailer cancelled, or because your forecast was wrong, or because the sales team over-ordered in the autumn and you are now working through stock. The factory is left holding yarn you did not order, on a programme you did not commit to, and the relationship is damaged over something you did not knowingly agree to.
The fix is not to stop sending forecasts. The fix is to make the commitment boundary explicit in the data itself, and in a written rule the factory’s sales and planning teams both see.
State it explicitly, and put it in the data contract: the forecast is a planning signal used for capacity reservation and material pre-buying. It is not a commitment to purchase, it is not an order, and it is never converted into an order without a purchase order.
Then handle the exception deliberately rather than hoping it does not arise. When the forecast changes materially — say, more than fifteen per cent on a line for the coming quarter — the buyer notifies the factory, so the factory can release or hold the pre-buy accordingly. A factory that has pre-bought yarn against your forecast and then learns from your file alone that the demand has halved is going to be unhappy; a factory that has been told, can adjust, and is thanked for the flexibility is a good supplier to keep. These are the same commercial outcome, reached by different information handling.
One further discipline: keep forecast accuracy visible. Track the variance between forecast and actual, by SKU family and by month, and review it with the factory quarterly. It is a genuinely useful conversation, because a factory that sees you forecast well will invest more effort in your capacity, and a factory that sees you forecast badly will discount your forecast when making its own plans — which quietly reduces the benefit you were trying to obtain.
Order creation is the easy part of integration. Change and cancellation are where the relationship is actually tested, because they are the messages that cost the factory money.
From the factory’s perspective, a change received before yarn is ordered is nearly free. A change received after yarn is dyed is expensive. A change received after the ribbon is woven and finished is a cancellation, and the cost of the finished goods plus the lost schedule slot may exceed the value of the goods themselves. Any integration design that treats change messages as routine line updates will produce that cost without the conversation that should accompany it.
A workable change framework has four parts.
A change window with published cost consequences. Define three windows and what each costs. The exact numbers are commercial, but the structure is standard: free before a stated approval milestone, a partial recovery of committed material cost between milestones, and a full loss calculation after production starts. Publishing the schedule of milestones in the data contract means both sides know the boundary in advance, which removes the argument at the moment it matters.
A change type on every change line. Never a generic update. The types that matter in ribbon are quantity, date, destination, specification, decoration and cancellation, and each has a different cost and a different downstream consequence. A destination change means a new packing list and potentially a new carton specification. A specification change means a new colour approval or a new artwork version, and the lead time restarts.
A lead-time restart rule. When a change resets the production schedule, state explicitly that the new delivery date is calculated from the reset point, not from the original order date. Without this, a buyer can change an order six weeks after placing it, restart the clock, and expect the original date — which is a reasonable expectation to hold and a reasonable thing for the factory to refuse.
An escalation path that is not the order message. Cancellations and large quantity reductions are commercial events. They should be raised by email or a call to a named contact, with the system message as the record. A cancellation that arrives only as a system message, handled by an automated process, is the kind of thing that damages a supplier relationship, and no buyer intends that.
One more point on cancellations, and it is a practical one. When you cancel, say what happens to the material. A factory that can use your yarn on another programme recovers most of the cost; a factory that has to scrap it recovers very little. Telling the factory “the order is cancelled, but if you can use the yarn for other work we would appreciate you working with us on the recovery” is a sentence that can turn a disputed cancellation into a managed one. You are not softening the decision. You are giving the other side the information they need to limit the damage, which reduces the amount that has to be argued about.
Every integration decays, and the cause is almost always the same: master data that nobody owns operationally.
A master SKU table that is set up correctly at launch and then left alone will have drifted within eighteen months. New colours get added by the design team and never given a factory recipe. An old construction is discontinued on the buyer’s side but remains in the factory’s catalogue. A width changes from 15 mm to 16 mm on the sample but the specification sheet is never updated. Each of these is individually trivial and collectively fatal to the integration, because every one of them is a case where the buyer’s system and the factory’s system describe the same SKU differently.
Four rules keep this under control.
Assign a named owner for master data on both sides. Not a department — a person, or at least a specific role with a name attached. In a ribbon relationship this is usually a product or merchandising person on the buyer’s side and a product or planning manager on the factory’s side. The owner’s job is not to create data but to keep the mapping valid.
Route every new item through a creation workflow. A new SKU should not become orderable in the ERP until the factory has confirmed it exists on their side with a construction, a recipe or an equivalent, a format and a lead time. This adds a day or two to the introduction of a new item and eliminates an entire category of error.
Version the things that change most, and review the rest. Artwork, colour recipes and decoration specifications change often and need version numbers with effective dates. Construction and format change rarely and need a periodic review rather than continuous vigilance. Trying to version everything produces version fatigue, at which point the versions stop being trusted.
Run a quarterly reconciliation. Export both master tables, compare them line by line, and list the differences. In a well-run relationship this produces a short list — a handful of new items, one discontinued colour, one artwork version that drifted. Doing it quarterly means the list stays short. Doing it annually means you will find forty differences and the reconciliation becomes a project instead of a routine. This is the single highest-return habit in the whole discipline, and it takes about an hour with a competent analyst and a spreadsheet.
Buyers consistently underestimate this, and the underestimation usually appears as a stalled project rather than a cost overrun.
Here is a realistic breakdown for a level-two implementation, which is the most common target. The figures are for the combined effort of both organisations, and assume a factory with a functioning order-management system.
| Activity | Combined effort | Notes |
|---|---|---|
| Data contract drafting and agreement | 5–10 days | The long pole. Mostly decision time, not writing time. |
| Master SKU table build and mapping | 4–8 days | Scales with SKU count and how messy the existing data is. |
| Message specification and mapping | 3–6 days | Order, acknowledgement, change, ship notice. |
| Technical build and testing | 6–12 days | File generation, parsing, error handling, logging. |
| User acceptance testing | 3–5 days | Run real orders through, including deliberate error cases. |
| Training and go-live support | 2–4 days | Especially for the factory’s sales and planning staff. |
Total: roughly 25–45 combined person-days across a six-to-ten-week elapsed period. That elapsed period is longer than the effort requires, and the difference is entirely the decision cycles — agreeing a field definition between two organisations who have not agreed one before.
Three cost items that get forgotten.
Data cleanup is not free. If your existing SKU data is inconsistent — and after a few years it always is — someone has to reconcile it before the integration, and that is real work that usually belongs in nobody’s budget. Budget a week.
Both sides need training. A factory’s commercial team is often unused to a strict order acknowledgement discipline, because the informal relationship had no need for one. Training them is a real cost and it is worth it, because the alternative is an integration that produces technically valid but commercially hollow acknowledgements.
The exception path is where the work lives. Every integration has an escape hatch for orders that do not fit the format — a special construction, a combined shipment, an unusual destination. The exception path needs to be designed explicitly, because an undocumented exception path becomes the main path within six months, and at that point you have built an expensive system that everybody bypasses.
Before committing your own technology budget, ask a candidate factory these nine questions. The answers will tell you whether an integration is worth building with them, and how much of the work they will absorb.
Question nine is the one most buyers skip and it is the one that predicts whether the integration will still work in a year. A factory with no named owner for the mapping will let it drift, and the drift will show up as a wrong construction on an order, a shade that does not match, and a dispute that nobody can resolve because the underlying data was never checked.
Notice that none of these questions are about the factory’s willingness to use modern technology. They are about process discipline, which is the actual determinant of whether integration works. A factory running a well-maintained order system with clear ownership will integrate well with almost any reasonable format. A factory without a maintained system will not integrate well with any format, however sophisticated the file.
What does integration actually buy? Three things, in increasing order of value.
Fewer errors. Not zero. A structured message removes the retyping step, and the retyping step is where most errors live. The specific errors that disappear are the ones you already know about: the quantity entered in the wrong unit, the width defaulted, the artwork from the previous season, the colour reference that the factory could not resolve. Each of those has a visible cost that you are probably already paying and not measuring.
Faster, more predictable lead times. This follows directly from the factory being able to plan. A factory that receives orders as structured messages, sees the forecast, and has a defined acknowledgement clock can sequence its work with real information instead of reactively. In a category with a seasonal peak and a Lunar New Year shutdown, the factories that plan well are the ones that deliver in December, and the ones that plan badly are the ones that explain in January.
A record you can actually rely on. This is the one that matters most and the hardest to quantify. After a season of integrated ordering, you can answer questions that are currently unanswerable: what did we actually order for the pink in March, what did the factory confirm, and what was the colour standard we approved at the time. When a quality claim arrives eleven months after the goods were made, the answer is not in a filing cabinet, it is in a transaction history that was accurate on the day it was created.
There is a fourth effect worth mentioning. A brand whose systems and its factory’s systems talk to each other is a brand that is difficult and expensive to leave. That is not the reason to do it, and it should never be the stated reason, but it is a genuine commercial consequence of having invested in an order-management relationship rather than a price comparison.
Our own order handling runs this way. We maintain a structured order-management system with item-level master data covering construction, colour recipe, format and decoration, return a line-level acknowledgement for every order, and work from rolling forecasts supplied by customers who book ahead — which is how we hold reserved production slots and group colours onto shared loom setups rather than re-sorting the schedule by whoever ordered first. Our factory in Xiamen runs more than 200 people at a daily output above 100,000 metres across our own 15,000 m² site, and the reason our lead times are dependable in peak months is that the plan is built from data rather than from a queue.
Smith Ribbon has been manufacturing ribbon, bows, tassels and decorative trim in Xiamen since 2004, with our own 15,000 m² factory, more than 200 employees, daily output of 100,000 metres, and certification including OEKO-TEX, FSC, BSCI, SEDEX/SMETA and ISO 9001. We ship to more than 50 countries and support OEM and ODM customisation from 1,000 metres, with small-batch runs from 500 metres.
We work with buyers through structured order exchange, returning a line-level acknowledgement for every order, working from rolling forecasts so capacity can be reserved ahead of seasonal peaks, and keeping master data for constructions, colour recipes and artwork versions under a named owner on both sides. Whether you need a data contract drafted for a factory that has never automated its order handling, an order file mapped to your ERP, a forecast-exchange arrangement with clear commitment boundaries, or a costed quotation for an integrated programme, send us your specification and we will tell you plainly what we can commit to and where the constraint sits.
Email: xmmsd@126.com | Mobile / WeChat: +86 137 7995 1780 | Office: +86-592-5095373
These are the questions buyers most often ask about integrating order and forecast data with a ribbon factory: whether EDI is worth the setup cost, what a data contract should contain, how forecasts should be used without creating unwanted commitments, which data errors cause the most trouble, how long implementation realistically takes, and what an order acknowledgement must include to make a lead time binding. If your question is not here, ask us directly.
It depends on order frequency and SKU count, not on factory size. EDI becomes worth the setup cost once you are sending more than roughly a dozen orders a month, or running more than about thirty active ribbon SKUs, because that is where keying errors and version confusion start costing more than the integration itself. Below that, a disciplined email or portal workflow with a numbered ordering rule will do the job at a fraction of the effort. The break-even is lower if your ERP already has EDI connectivity to other vendors, because the marginal cost of one more trading partner is then a configuration exercise rather than a project.
A data contract is the written agreement on what each field in an exchanged message means, who owns it, what format it uses, what happens when it is wrong, and which version is authoritative when systems disagree. It typically covers the SKU identifier scheme, the unit of measure, the currency and Incoterm, the ship-to and bill-to structure, the lead-time promise, the colour and decoration references, and the acknowledgement clock. Without it, both sides believe the other understands the data, and the resulting disputes are not technical errors but interpretive ones, which are the hardest to resolve.
Send forecasts, but be explicit about what they are. The useful contract is: the forecast is a planning signal used for capacity reservation and material pre-buying, it is not a commitment, and it is never converted into an order without a purchase order. Specify the horizon, the granularity, the confidence band, and the update frequency. Give the factory a rolling twelve-month view at SKU-by-month level, state the date the forecast was generated, and agree a rule for what happens when actual demand diverges sharply, so that neither side is guessing about which numbers were authoritative on which day.
The most common are, in order of frequency: mismatched SKU identifiers where the buyer uses an internal code and the factory uses its own, quantity given in metres when the system assumes rolls, the width and construction attributes not carried in the order line so the factory defaults to a standard construction, colour referenced by name rather than by a code, and the same SKU appearing in several versions after a specification change. Almost all of these are solved by a single master SKU table that both systems reference, rather than by sending the attributes in every transaction.
For a simple CSV or portal-based exchange with one factory, two to four weeks is realistic, most of which is spent agreeing the field definitions rather than on the technology. For a full EDI trading relationship with order, acknowledgement, order change and invoice messages, allow six to twelve weeks, because the long pole is mapping the buyer's ERP data model onto the factory's and agreeing the acknowledgement rules. Neither figure is unusual, and any factory that promises a live EDI link in under two weeks without a written data contract is proposing to discover the field definitions later.
At minimum: the factory's own order reference, the acknowledgement status, the confirmed quantity per line, the confirmed price and currency, the confirmed delivery date calculated from the agreed lead time, the line-level split where a quantity is delivered in more than one shipment, and the shipment or production dates that produce that delivery date. It should be returned within a fixed window agreed in advance. The acknowledgement is where a lead time becomes binding, and a factory that confirms a date without the production date that supports it has confirmed a guess.