A packaging specification control system should decide the approved box, cushioning, label and packing method before an operator starts. For a Thai plant serving several customers and export destinations, a product code alone rarely identifies the right instruction. Customer, SKU, destination, revision and effective date all matter. This guide explains how to build a governed packaging bill of materials (BOM), approve changes, issue the right instruction to the line and connect ERP, MES and WMS. It also provides practical RFP and FAT/SAT criteria.
What belongs in a packaging specification master?
A specification covers inner pack, outer case and pallet levels; quantity at each level; box, divider and cushioning material; label version and position; sealing; weight and dimensions; work sequence; and inspection requirements. SAP EWM documentation describes a packaging specification as master data defining levels, quantities, materials and sequence, and notes its use as a warehouse worker instruction. The same management principles apply whether the master sits in SAP or another system.
Think of a packaging BOM as a structured relationship: for customer A, SKU P-100, export destination Japan, revision R3, one case contains ten finished units, one BX-20 box, two CU-04 cushioning pieces and one LB-A7 label. Its effective condition might be “shipments dated from 1 November 2026.” Those codes and dates are examples, not real customer data. Structured material lines allow purchasing, line instructions, comparison and traceability to use the same approved source.
Separate the required specification from the packing execution record. The latter holds the operator, time, material lot, scans, exceptions and shipment or handling-unit ID. Keeping both lets the plant answer two different audit questions: “What was approved at that time?” and “What was actually used?” Overwriting the master with execution results destroys that distinction.
Why a shared spreadsheet is often insufficient
The risk is not a spreadsheet cell in isolation. The risk is an inconsistent combination of conditions. Sales may have the latest customer PDF, engineering a revised material list, purchasing an open order for old cartons, and the line an earlier printed sheet. One shared folder cannot by itself define who approves a change, which order it affects, when it becomes effective, and how an old instruction is withdrawn.
Paper instructions can remain useful. Generate them from an approved revision, print the specification ID, revision, issue time and applicability on each copy, and assign responsibility for removing old copies. A handwritten correction should trigger a controlled change, not silently become the master. A terminal is a way to make these rules more dependable; it does not replace the rules.
Use customer, SKU, destination, revision and effective date as the decision key
The minimum master header should include specification ID, customer code, product SKU, destination or ship-to, revision, approval status, valid-from and valid-to conditions. Depending on the operation, plant, line, order type, carrier or transport mode may matter. Every extra condition increases the chance of overlapping records, so define precedence deliberately.
The order or production instruction should supply the customer, SKU, destination and business reference date. Select approved, effective specifications, then choose exactly one matching record under a documented precedence rule. If none or more than one remains, hold the instruction and alert its owner. Do not select the first row silently. SAP’s specification determination documentation describes condition records and explicitly warns about overlapping keys within a validity period. That is a useful acceptance test even for a custom application.
Define what “effective from 1 November” means: production start, packing start, dispatch or customer receipt. Decide how work in progress and old materials are treated. Record time zones explicitly when the plant and customer are in different countries. Selecting by the server’s current date alone may apply a new revision to a shipment produced early under a prior approval.
Split header, material lines and applicability
The header records ID, name, revision, state, requestor, approvers, reason and customer approval reference. Material lines record pack level, item code, quantity, unit, case count, sequence, allowed substitute, label artwork revision and placement. Applicability records customer, SKU, destination, plant or line, and valid period. Preserve links to approved drawings and material specifications as they existed at approval time. A “show latest file” link cannot reliably reconstruct an old shipment.
Connect the internal packaging BOM to GS1 packaging hierarchy
An internal BOM and a trade-item hierarchy are related but different. GS1’s Global Data Model guide describes linked identification levels such as unit, pack, case and pallet. Internal cushioning does not automatically need its own GTIN. What matters is distinguishing trade units that customers order or receive from the consumable components used to create them.
A case-quantity change may have identification consequences. The GS1 pack/case quantity rule says that changing the number of trade items in a case, or cases in a predefined pallet configuration, requires a new GTIN at the affected higher packaging level. GS1 also publishes a dimensional and gross-weight change rule. Apply the appropriate GS1 rule, contract and local regulation to each product rather than assuming every packaging change has the same outcome.
For example, changing a case from ten pieces to twelve affects the customer order unit, WMS capacity, pallet configuration, advance shipping notice and possibly the printed case label. Add a change-form field for “GTIN review required/decided,” the decision owner and the old/new cutover. That prevents a change called “just a box update” from bypassing customer-facing data.
Design approval around the decisions each role makes
Sales or customer service owns the original customer request and external approval. Engineering checks protection and pack structure. Quality checks label content and inspection criteria. Purchasing verifies item codes and availability. Logistics checks case count, pallet and transport constraints. Manufacturing verifies the actual work sequence and equipment. The mandatory approvers depend on the product and customer agreement.
Use states such as draft, departmental review, customer review, approved, active and obsolete. Never edit an approved revision in place. Create a new revision, show a machine-readable difference and preserve the prior one. SAP engineering change documentation describes change reasons, effectivity, change logs and revision levels; these are valuable reference concepts for packaging governance too.
A useful difference view says “BX-20 → BX-21; ten per case → twelve; LB-A7 → LB-A8,” then lists affected orders, work in progress and stock. Decide whether old material may be depleted, whether two versions may coexist and whether the customer must approve an exception. Store the decision, approver and expiry date, not only a generic “approved” flag.
Issue a fixed revision to each production or packing order
The line terminal should not merely offer a searchable list of “latest specifications.” Scanning an order or lot should resolve a specification ID and revision, then show its permitted box, cushioning, label, quantities, placement and inspection steps. If the order changes after release, define whether to re-evaluate, split the order or finish work under the old revision.
Display instructions in the order operators perform them: identity and revision, materials and quantities, placement and checks. If workers scan packaging materials, validate both normal and approved substitute codes against the selected revision. For an unreadable barcode or emergency substitute, record the reason, approver, material and quantity. An exception must remain visible as an exception in later analysis.
Pictures help the worker but should not be the sole source of truth. Structured fields support calculations and change comparison; approved drawings and photographs explain the physical action. If a network outage requires paper fallback, include an issue number and expiry time and specify how execution data is entered after recovery. Cached instructions need a visible synchronization time and a rule for when stale data blocks work.
Divide responsibilities across ERP, MES and WMS
The exact architecture varies, but assign one authoritative owner per data field. ERP commonly owns customers, SKUs, sales orders, materials, purchasing and costs. MES owns production orders, line events, scans and inspections. WMS owns storage, picking, handling units and shipment units. The packaging specification master owns the rule connecting order conditions to approved packaging materials and work instructions. It can live in an existing ERP or WMS if that system meets the requirements.
Typical flows are ERP → specification master for customer, SKU, destination and material identifiers; specification master → MES for selected revision, material lines, instruction and checks; specification master → WMS for case count, dimensions, weight and pallet pattern; MES/WMS → execution history for used materials, handling unit and exceptions. Write down each field’s source, frequency, retry rule and error owner. Two systems that can independently modify the same revision will eventually disagree.
Test failures before designing only the happy path: missing ship-to, retired material, order date change, zero or multiple matching specifications, incomplete label approval, an order already started under the old revision, or an interface timeout. The system should show a hold and named escalation instead of silently reusing a previous value. SAP packing-instruction documentation similarly distinguishes the instruction itself from records that determine when it is used.
Prepare a migration ledger before building screens
Start with currently shipped combinations of customer, SKU and destination. For each, collect the customer PDF, current spreadsheet, line sheet, packaging item codes and observed physical pack. Record the former file and revision, evidence source, observation date, owner, new specification ID and unresolved questions. Find orders without a specification, specifications with obsolete materials and overlapping approved records.
Run every active order line through the decision logic. A single approved match passes. Zero means missing data; two or more mean conflicting conditions. Display the conflicting keys. A more specific destination rule may outrank an all-destinations default, but two records with the same precedence must be corrected by the data owner. Do not silently fill unknown quantities from an old file. Mark them unverified until a drawing, purchase specification or physical measurement supports them.
Prioritize high-volume, frequently changed or high-impact products. Dormant products may remain blocked from automatic release until their master is verified. In multilingual plants, keep codes and quantities as common structured data and translate only the work instructions. Build a glossary for terms such as inner pack, outer case and cushioning; require approval of each language used on the line.
Master-data quality needs a continuing control. Re-run the one-match test whenever a new SKU, destination, material discontinuation or label revision is approved. Show the change approver how many open orders are affected and how many would become unmatched.
For go-live cutover, do not represent the old/new revision transition with a single date. Build a decision matrix for four separate objects: customer orders, work in progress, packaging-material stock and shipments. For each order, list customer, SKU, destination, promised dispatch date, planned packing start and the specification ID and revision to be applied. State whether work already packed under the old revision may finish that way or must be unpacked and changed. Separate old and new boxes by lot and storage location, and record the conditions under which substitution is permitted. At dispatch, compare the revision fixed to the order with the box and label revisions actually used. If the customer’s cutover is based on arrival date, agree on transit time and exception treatment rather than assigning versions solely by dispatch date.
Migration reconciliation is more than a count of imported records. Sample representative orders for each customer and destination, orders on both sides of the effective-date boundary, the last order using old material and the first using new material. Compare four things: the old spreadsheet, the original customer requirement, the new system display and the physical packaging. If they differ, the owning department must decide which is authoritative and record the correction and recheck. Also sample historical shipments and confirm that the migrated history can reconstruct the instruction and approval valid at the time. This can reveal a missing basis for an old revision even when new records appear to have loaded successfully.
Do not bury cutover exceptions in a free-text note field. Give each one a customer, SKU, shipment scope, permitted old material, start and end time, customer-approval status, internal approver and action after expiry. When an exception expires, check for unfinished orders before closing it. At each shift handover, list the orders still relying on exceptions and any unresolved stock, and give the list to the next responsible supervisor. Assign one owner to the cutover matrix so that sales, purchasing and the line do not each declare a different moment of “completion.”
How should you estimate cost and benefits?
Break a quotation into process study, data cleansing, master design, approval workflow, line terminal, ERP/MES/WMS interfaces, document or label connection, migration, training, FAT/SAT and support. Compare recurring subscriptions, custom development and terminal hardware separately. Network reliability, backup and security can materially change scope.
Illustrative calculation only, not a measured result or TOMAS TECH quotation: suppose a plant creates 12,000 packing orders a year and reduces specification lookup from three minutes to one. That is 12,000 × two minutes = 24,000 minutes, or 400 hours. At an assumed THB 400 per hour, the gross time value is THB 160,000 a year. Subtract master maintenance, training, terminal operation and exception handling before estimating net value. For mispack reduction, establish the current incident count and definition first, then measure on the same basis after go-live. Treat a rare shipment-stop scenario separately instead of hiding it in an average.
Duration depends on customer approvals, data quality, API restrictions and plant rollout, not simply SKU count. A proof of concept can use two customers, two product families, two destinations and one revision cutover. Its purpose is to test decision logic and work practice with real data, not to upload the whole catalog.
Put testable conditions in the RFP
“Manage packaging specifications” is too vague. Ask vendors to demonstrate exact input, output and failure behavior.
| Requirement | Example acceptance condition |
|---|---|
| Selection | One approved record for customer, SKU, destination and reference date; zero/multiple hits cause a hold |
| Revision | No direct overwrite of approved revisions; preserve differences, reason, approver and effectivity |
| Packaging BOM | Hierarchical box, cushioning, label and pallet lines with quantities |
| Line instruction | Order scan fixes the revision; material scan and exception approval are logged |
| Interfaces | Field owner, update frequency, retry and error escalation are specified for ERP/MES/WMS |
| Audit | Reconstruct the specification, instruction, materials and approvals for an old shipment |
| Access | Separate draft, approval, activation and exception privileges |
Add the languages used on site, response expectations under real device and network conditions, outage mode, retention, backup, recovery and security rules. Ask vendors to identify what is standard configuration and what is custom work.
FAT and SAT scenarios that reveal real risk
FAT should check configuration, decision logic, interfaces and exception paths with test data before site installation. SAT should test the actual terminal, printer, network, worker and packaging materials at the plant. Contract definitions vary; agree on scope and pass criteria in advance.
Test the same SKU for different customers, the same customer for different destinations, before/after effectivity, work in progress, pending approval, overlapping records, missing records, approved substitutes, unreadable scans, printer failure, network failure, order change and WMS interface failure. Write the expected specification ID, revision and materials before the test. A plausible but wrong instruction is more dangerous than a visible error.
During SAT, observe whether an operator can read the display under normal line conditions and scan while wearing gloves. Confirm that a change notification removes old printed sheets. Trace a shipment back to its approved historical revision and material use. Record each outcome as passed, conditionally passed or failed, with an owner and due date for unresolved items.
Where the specification master stops
The master decides what should be packed. Image-based verification of the finished box is a downstream control; see AI verification of shipping packaging. The approved master can supply the target for that check, while scans or weighing may still be needed for cushioning hidden inside a box.
Artwork revision control is also distinct from deciding when and where a label version applies. Connect the approved file in manufacturing label version control to the packaging specification. Reusable boxes add ownership, returns, cleaning and cycle history; see returnable container management. Keep those processes linked without making one master responsible for all of them.
A practical implementation sequence
First, inventory current instructions and assign data and approval owners. Second, model a small set of real customer/SKU/destination combinations and test revisions and effectivity. Third, add ERP, MES and WMS flows one direction at a time, including failure handling. Fourth, expand scope, retire uncontrolled files, train operators and audit the result.
After launch, monitor orders blocked by missing specifications, duplicate matches, use of obsolete revisions, exception approvals and time from change approval to line availability. These metrics should expose data and process problems, not merely rate individual operators.
FAQ: Is ERP alone enough for packaging specification control?
Yes, if it can select the approved revision using all required conditions, manage hierarchical materials, approvals, line instructions and historical reconstruction. If a separate application fills gaps, decide which system issues specification IDs and controls approval. Do not permit independent edits in both.
FAQ: What does implementation cost?
There is no useful universal price. The main drivers are branching by customer and destination, existing-system interfaces, devices, data cleanup and acceptance scope. Define representative products, migration volume, approvals, integration fields and FAT/SAT cases before comparing quotations. Include the operating cost of keeping masters accurate.
FAQ: Can a customer’s PDF be registered directly?
Keep the original PDF as evidence, but extract customer, SKU, destination, case count, materials, revision and effectivity into controlled fields. Check ambiguous notes and drawing callouts with a responsible person before approval. Automated extraction does not remove the need to verify the physical pack.
FAQ: What if old packaging materials remain on the change date?
Check customer permission, work in progress, inventory lots and any permitted substitute. Record a time-limited transition decision and keep the revision used on each shipment. Neither silent depletion nor automatic disposal is a safe default.
FAQ: Should several plants share one packaging specification revision?
If the customer-approved packaging structure is common, the plants can share its ID and revision while maintaining plant-specific work instructions and equipment settings at a lower level. If locally available materials or pallet requirements differ, the shared customer specification alone must not release a line instruction. Store both the customer-level and plant-execution revisions with each shipment. Define whether a change at one plant flows to another automatically or requires a local review. The common revision may be approved centrally, while activation at the Thai plant waits for site acceptance or a first-article check. Give local exceptions an owner, reason, expiry and affected line, and review them regularly.
Conclusion
Begin with the rule that selects one approved revision for one order. Structure boxes, cushioning, labels and pack quantities as a packaging BOM; connect approval, line instruction and execution history; and define ERP/MES/WMS ownership. Put missing and conflicting records, revision cutovers and interface failures into the RFP and FAT/SAT. Those controls make the system useful during real production changes.
If your Thai plant is still aligning customer PDFs, spreadsheets and line instructions, you can discuss the master structure, change process and integration scope with TOMAS TECH while the project is still being scoped. One representative SKU and a recent change are enough to start a concrete conversation.
References
- SAP: Packaging Specification
- SAP: Packaging Specification Determination
- SAP: Engineering Change Number
- GS1: Global Data Model Attribute Implementation Guide
- GS1: Pack/case quantity
- GS1: Dimensional or gross weight change
- SAP: Preparing Packing Instructions for Packing in Embedded EWM
*Sources checked 18 October 2026. Confirm the applicable customer agreement and local rules for each product.*
