2.5 Documentation & Traveler Control
How to record rework, update serial status, and protect traceability.
In electronics manufacturing,
adocumentation and traveler orcontrol MESform the backbone of traceability. Each unit’s record is more than paperworka —log—it it’sis the singleauthoritative sourceaccount of truthevery forprocess, each unit’s history. It ties together identity, process recipes, component genealogy, inspection results,inspection, and any rework actions so there’s no mystery about what happened, when, and by whom. Strong traveler control prevents lost boards, duplicate serials, and undocumented fixes, whilestep, ensuring that anynothing repairedis unithidden automaticallyand passesno backboard throughgoes untracked. When maintained with discipline, the righttraveler inspectionsprevents beforeduplication, shipping.enforces Clearre-inspection statusafter rules, complete rework tickets,repairs, and controlledprovides labelthe handlingevidence protectneeded to prove both traceabilitycompliance and quality. By keepingconsolidating all datahistory ininto onea systemsingle —controlled notsystem, scattered across sticky notes, side spreadsheets, or chat threads — teamsmanufacturers turn repairindividual eventsfixes into documented,collective auditableprocess knowledge thatwhile supports bothsafeguarding customer confidence and future process improvement.
2.5.1 Why this matters (in one page)
If the traveler/MES record tells the whole story, boards don’t get lost, labels don’t lie, and quality actions actually stick. Your goals:
- Every unit (SN) has an unbroken history from parts → board → box.
- Any rework is visible (who/what/when/how), with proof.
- The route after rework forces the right re-inspections before “PASS.”
- No shadow data (sticky notes, side spreadsheets, chat photos).
House rule: No traveler, no work. No scan, no move.
2.5.2 What the record must contain (per serial)
Log these once per unit and update on changes. Keep it boringly complete.
If your system can’t attach files, fix the system—not the discipline.
2.5.3 Simple status model (so routing is automatic)
Rule: after REWORK, the route must include the failing station again (and any downstream affected). No hopscotch.
2.5.4 Rework ticket: fields that end arguments
- SN / Refdes / Side
- Defect code (controlled list), short free-text note if edge case
- Evidence: AOI/AXI images, scope traces, reflow plot snippet
- Action: what was done (paste/flux, temps, nozzle, part PN/lot replaced)
- Attempt count (per refdes) and heat cycles if relevant (BGA/QFN limits)
- Who/when (operator/tech/QE)
- Verification step(s) required (AXI, AOI, ICT, FCT) + result links
Close only when verification passes and status moves to PASS via the routed gates.
2.5.5 Serial numbers & labels (no duplicates, no ghosts)
- One SN = one physical unit. Reuse never.
- Reprint = same data, same barcode, reprint reason logged; old label destroyed.
- Label corrections: void the wrong label in MES (status = VOID), apply corrected, attach photo.
- Board↔box mapping: scan all board SNs into the box SN; block pack if the map is missing.
- Marking after rework: if you add or alter DPM/label, log new code in the SN record (Section 4.x practices).
2.5.6 Genealogy updates (parts you swap must leave footprints)
When you replace a component:
- Scan the new part PN + lot/date into the SN’s child list.
- If you remove a part, mark the old lot as removed (so supplier returns/SCARs find it).
- For security items (keys, unique IDs), record new values and invalidate old.
This makes supplier issues traceable without digging through benches.
2.5.7 Route after rework (the “must-pass” list)
Map defect → required verifications:
MES should insert these steps automatically when the ticket closes.
2.5.8 Paper traveler backup (when MES blinks)
- Pre-printed barcoded travelers with minimal fields: SN, WO, Product Rev, status boxes, signature lines.
- On recovery, back-enter: timestamps, actions, photos (taken during outage), then retire paper with a scan.
- No paper-only work beyond a shift; if outage persists, declare controlled stop or bring up a light offline tracker that imports to MES.
2.5.9 Common scenarios (do this, not that)
A) BGA rework late in test
- Do: Move SN to REWORK, perform controlled rework (14.3), AXI, then rerun failed FCT steps (and any power rails).
- Don’t: Wave it through because “it now boots.” AXI or it didn’t happen.
B) Box opened for board swap (RMA)
- Do: Break board↔box map, set box HOLD, create child traveler for the board, repair & re-test, then rebuild the map and close RMA with notes.
- Don’t: Swap and scribble—mapping must match reality.
C) Label smudge at pack
- Do: Reprint with same SN; attach photo; VOID old in system.
- Don’t: Handwrite. Ever.
D) ECO mid-lot
- Do: Traveler shows ECN ID, split WIP into pre-/post-ECN lots; recipes and AOI programs rev’d; pack labels carry as-built rev.
- Don’t: Mix silently—this makes root cause investigations miserable.
2.5.10 Roles & permissions (who can touch what)
Tight permissions prevent accidental “greenwashing.”
2.5.11 Guardrails against shadow data
- Block pack-out if any of: open ticket, missing AXI/AOI link for required rework, missing firmware hash, broken board↔box map.
- Auto-import images from AOI/AXI/test into the ticket (no manual upload to chat).
- Dashboard tile: “Units in REWORK > 24 h” and “Reprints today” (count & reasons).
- Weekly audit: pick 5 PASS units → verify images, genealogy, programming match labels.
2.5.12 Pocket checklists
At fail (operator)
- Scan to NG-QUAR; ticket auto-created
- Defect code picked; image/plot attached
- Unit parked in quarantine rack
At rework (tech)
- Claim ticket (REWORK); log action, temps/tools
- Scan new parts (lot/date); update attempt count
- Run required verifications; attach results
At close (QE/lead)
- All required gates re-passed (MES shows green chain)
- Status → PASS; comments “why fix worked” noted
- If label reprint: old VOIDed; photo saved
At pack
- Board SNs ↔ box SN mapped; firmware ID printed if required
- Traveler signed; CoC generated (if needed)