Order information rarely stays still. A buyer may change a date. A technical team may approve a new measurement. Planning may refresh material needs. Quality may add an inspection result. Logistics may update a shipment milestone. The problem is not that information changes. The problem begins when several copies of the order continue to circulate after a change and nobody can tell which copy is current.
The practical rule is simple: one live order record must show the current approved value, while the history of earlier values stays traceable. People may work in different systems, files or departments, but they must not create several competing current versions. A good process records what changed, who approved it, when it became effective and which older copy is no longer valid for new work.
You need: the ownership rule from Lesson 1.1 — each important data item has an accountable owner, an approved source and an update path.
By the end of this lesson you can:
Not covered here: software configuration, database versioning, document-management products or legal record-retention rules. This lesson teaches the operating method first.
| Term | Meaning |
|---|---|
| Current approved record | The one record accepted for new operational decisions now. |
| Revision | A controlled change to information that produces a newer approved state. |
| Superseded copy | An older copy that is kept for history but must not be used as the current instruction. |
| Change log | A simple history showing what changed, who approved it, when it changed and what was affected. |
| Effective point | The date, time or event from which the new approved value must be used. |
| Version conflict | A situation where two records show different values and both are being treated as current. |
A controlled process separates current from historical. The current approved record is the value people should use for the next decision. Earlier values may still matter for audit, learning or explaining what happened, but they should be marked clearly as superseded. This prevents a planner from buying against one quantity while costing, production or packing uses another.
The rule applies even when there is no advanced system. A shared workbook, controlled folder or simple order tracker can work if the team agrees which location is current, who may approve changes, how revisions are identified and how old copies are prevented from looking live.
| What can differ | The shapes you will meet | Why it matters to you |
|---|---|---|
| Where the current record lives | ERP screen, PLM record, shared tracker, controlled spreadsheet or document-management folder. | The technology can differ; the team still needs one agreed current location. |
| How revisions are named | Revision number, date-time stamp, approval status or a controlled sequence such as Rev 03. | A name is useful only when people know which revision is current and which is superseded. |
| How changes arrive | Buyer email, portal update, meeting decision, approved sample comment or internal department update. | The arrival channel is not automatically the approved source. The owner must validate it. |
| When a change becomes effective | Immediately, from a stated date, from the next production batch or only after written approval. | Teams must know the effective point before changing work already in progress. |
| Different product families | Socks may change yarn or size assortment; knit-to-garment may change gauge or measurements; terry may change size/GSM; bedding may change component dimensions. | Different fields change, but the current-versus-history rule stays the same. |
Order A is already confirmed for 15,000 T-shirts. Mona receives a buyer message that changes one operational instruction. At the same time, planning has a local spreadsheet, procurement has an emailed attachment, and production has a printed copy from the previous day.
Mona does not solve the problem by forwarding another attachment called `FINAL_v7_REAL_FINAL.xlsx`. She first checks whether the buyer message is the approved instruction, identifies the owner who must accept the change, updates the one controlled order record, marks the previous revision as superseded and tells every downstream user exactly which revision is now in force.
The old copy is not deleted from history. It is made impossible to mistake for the current instruction.
The worked numberOrder A remains 15,000 pieces with approved consumption of 0.205 kg per piece.
Suppose planning has an old local copy with a different quantity. The planning formula might still calculate perfectly, but it would calculate from the wrong version. The correct control is not to compare formulas first. It is to confirm which quantity is current, then refresh every dependent calculation from that approved value.
The same logic applies to the order value:
One version conflict can therefore produce inconsistent material requirements, commercial totals and capacity decisions even when every individual formula is correct.
Email time, file creation time and a word such as "final" in the filename do not prove approval. A later email can contain an unapproved suggestion. An older controlled record can still be correct until the responsible owner approves the change. Teams get into trouble when they use chronology instead of authority.
The safer question is not "Which file is newest?" It is "Which approved revision is currently effective, and where is that recorded?"
A change log that nobody opens is decoration, not control. The habit that makes version control work is small and repeatable: before booking material, confirming a measurement or releasing an instruction downstream, a person checks the current record first and only then acts. This single habit prevents most version conflicts, because it stops someone from acting on a copy that feels current but was never confirmed against the approved source.
The log itself should stay simple enough that people actually use it. A short row for each change — what changed, who approved it, when it became effective and who was told — is usually enough. Adding more fields than a team will realistically fill in only teaches people to skip the log altogether, which quietly recreates the very problem version control is meant to solve.
It also helps to name one person, not a rotating group, as responsible for confirming that the current record is up to date before a busy day begins. A shared responsibility without a named owner often means nobody checks, and the team discovers the version conflict only after work has already started on the wrong copy.
Imagine several people editing photocopies of the same order. If nobody controls which copy is current, every department can be working hard and still be working from different instructions. Version control means there is one copy for current decisions. Older copies are kept only so you can see what changed.
When a change arrives, do not just send another file. Confirm the change, update the controlled record, mark the old one as superseded, and tell everyone who depends on it.
Sara at Northline Apparel has a buyer-side tracker. Mona at Delta Garments has the factory order record. A change was discussed yesterday, but Sara's tracker and Mona's record now show different values. Neither file is marked wrong, and each person genuinely believes their own copy is correct because each updated it in good faith right after the conversation. Procurement is ready to book material and is waiting on whichever number the two teams confirm.
What should the team do before procurement acts? Decide before opening the answer.
Stop the dependent action briefly and resolve the version conflict at the approved source.
1. Identify the exact field that differs instead of saying only that "the files do not match." 2. Check the approved source and the accountable owner for that field. 3. Confirm whether the proposed change was approved and when it becomes effective. 4. Update the one current buyer/factory agreed record and mark the other live-looking copy as superseded or corrected. 5. Recalculate any dependent figure and tell procurement which revision is now in force before booking material.
For Order A, the accepted current quantity remains 15,000 pieces, so the approved fabric requirement stays 3,075 kg unless an authorised quantity or consumption change is formally accepted.
Order A has a total FOB value of USD 48,000. That does not mean every version error costs USD 48,000. It shows the scale of the commercial record that depends on controlled inputs.
A stale quantity can flow into material booking. A stale specification can reach production. A stale ship date can distort planning. The direct cost may be rework, excess material, missed capacity, delay or urgent freight. The management cost is also real: people spend time comparing files, rebuilding history and arguing about which instruction was valid.
A short controlled revision step is cheaper than repairing several departments after they have acted on different versions.
Open the T17-C01 Data ownership and data quality workbook. Record the field changed, the old value, the new value, the approved source, the owner, the effective point and every downstream user affected. Keep the current value visible in the ownership matrix and use the change log for history. Do not maintain two separate "current" rows for the same field.
[Download the Data ownership and data quality workbook](../../templates/T17-C01-data-ownership-data-quality.xlsx)
1. What is the safest meaning of a current approved record?
2. Why should a superseded revision usually be kept?
3. Order A remains 15,000 pieces at 0.205 kg per piece. What must the controlled material requirement show?
| EN | AR | FR | TR | Meaning |
|---|---|---|---|---|
| Current approved record | السجل الحالي المعتمد | Enregistrement approuvé en vigueur | Güncel onaylı kayıt | The one record accepted for new operational decisions now. |
| Revision | نسخة معدّلة | Révision | Revizyon | A controlled change that creates a newer approved state. |
| Superseded copy | نسخة مستبدلة | Copie remplacée | Geçersiz kılınmış kopya | An older copy kept for history but not for current instruction. |
| Change log | سجل التغييرات | Journal des modifications | Değişiklik kaydı | A history of what changed, who approved it and when. |
| Effective point | نقطة السريان | Point d'entrée en vigueur | Yürürlük noktası | The date, time or event from which the new value must be used. |
| Version conflict | تعارض الإصدارات | Conflit de versions | Sürüm çakışması | Two records showing different values while both are treated as current. |
Next you will learn a practical data-quality check for completeness, validity, consistency and timing before information is handed off. Back to the course map