RFQ and technical guide
Unit-to-Carton Barcode Mapping: Define the Parent-Child Relationship
Define which garment-unit identifiers are associated with each carton identifier and when that relationship becomes authoritative. A parent-child mapping is a contents association, not merely a matching product code. Specify what happens when units move, cartons split or a relationship cannot be confirmed.
For apparel operations teams preparing warehouse data requirements.
Distinguish product identity from physical-unit identity
Ask whether the proposed unit label identifies a product variant or an individual physical garment. A shared style-and-size code cannot by itself distinguish one unit from another. If the workflow needs individual-unit aggregation, state that requirement and ask whether the proposed labeling supports it. Keep the carton identifier in its own field. Do not assume a recognized barcode format supplies the required hierarchy; the encoded identifier and its associated data relationship are separate parts of the brief.
Define when the contents association is created
Name the proposed packing step that establishes which identified units belong to a carton. Ask what record is produced and which party can access it. Describe the required fields, including the parent identifier, child identifiers and relationship status. This is different from asking for a log of scanning events: a series of scans may not establish the final packed contents unless the workflow defines that meaning. Request a sample data record before approving an interface description.
Handle repacking without leaving two active parents
Specify what the project expects when a unit moves from one carton to another or when a carton is split. Ask how the earlier association is closed and the new one recorded. Retain the history if the agreed traceability scope requires it. Avoid silently adding the same physical unit to two current cartons. If the workflow uses non-unique product codes, make that limitation explicit rather than pretending the record can prove individual-unit movement.
Agree mismatch handling and evidence at handoff
Describe how a missing child identifier, duplicate association or unexpected unit should be reported. Ask who can correct the relationship and what confirmation is required before the carton record is released. Keep physical contents reconciliation distinct from file-format validation: a well-formed data file may still describe the wrong packing state. Request a representative handoff record with its limitations. Do not assume that the supplier, buyer warehouse and carrier already share one live aggregation database.
Decision and evidence checklist
| Decision | Include in the brief | Review evidence |
|---|---|---|
| Identifiers | Variant code versus unique physical unit | Label and data examples |
| Aggregation | Parent, children and authoritative step | Sample relationship record |
| Change | Repacking and correction authorization | Closed and current associations |
What this brief does and does not establish
This proposes data requirements, not an implemented MyOwnWear barcode service or a barcode-standard certification. No serialization, warehouse integration or live database capability is promised. Confirm identifier rules, system support and physical reconciliation separately.
Attach an example of the required parent-child data and repacking rules when discussing garment packaging requirements. Open the MyOwnWear RFQ form.
Buyer questions
Does a size SKU identify one physical garment?
Not necessarily. Confirm whether the identifier is unique to a unit.
Is a scan log the same as a contents map?
No. The workflow must define which associations represent final contents.
Does valid data prove the carton contents?
No. Physical reconciliation and data-format checks answer different questions.