WMS / ERP barcode readiness for Hong Kong businesses
Barcode Data Fields to Prepare Before a WMS or ERP Project
A barcode project should not begin with the question, “Which scanner should we buy?” Begin by deciding what each barcode identifies, which system owns the data, which record a scan should update and who resolves an exception. A field map covering items, units, locations, lots, serial numbers, orders, permissions and error rules gives your implementation team a much clearer starting point.
Name the owner of every important field
Item codes, barcodes, packaging, locations, lots, serials, documents and inventory status should not be changed independently in several systems. Give every object an authoritative source and update direction.
Tell the system what should happen after a scan
A code may identify an item, location, document or logistics unit. Map every scan point to a screen, field, validation and transaction rather than checking only whether characters appear.
Wrong codes, shortages, duplicates and outages need routes
A dependable workflow handles more than the happy path. Unknown codes, wrong locations, duplicate messages, network interruptions and count variances all need clear messages, owners and audit records.
Separate the data layers
Database fields, encoded barcode data and visible label text are different
Putting every available value into one barcode is rarely the safest design. Encode only what the scan workflow needs to identify. Price, availability, order status, permissions and business rules normally remain in the application and are retrieved after identification.
Fields used to govern and link system records
Examples include internal SKU, item description, pack level, base unit, conversions, warehouse, location, tracking policy and status. These values need owners and controlled revisions.
The string that the scanner sends to the application
It may be an internal code, GTIN, location code, document number, SSCC or composite GS1 data. GS1 Application Identifiers define the meaning and format of individual data elements.
Information that a worker or recipient can read
Human-readable interpretation, item names, quantities, locations and handling instructions support checking. Visible text is helpful, but it should not become an uncontrolled substitute for a unique system key.
Receiving must align the goods, document and system record
A supplier barcode may not equal your internal SKU. Build a governed cross-reference between supplier codes, GTINs, pack codes, internal items and units so a carton is not received as one base unit.
Give every identifier one stable business meaning
If the same code sometimes means a product, sometimes a pack and sometimes a logistics unit, scanning becomes ambiguous. Each active code should resolve to one intended business object and packaging level.
12-point readiness checklist
Prepare these decisions before a WMS or ERP barcode project begins
This is not a demand to create every possible field. It helps you decide which data applies, who owns it and how it will be tested. Field names and behaviour differ between ERP, WMS and POS platforms.
Process and decision owners
Name the business owners for receiving, putaway, picking, packing, shipping, counting, POS sales and returns, plus the IT owners for ERP, WMS, devices, label printing and networks.
Source of truth for each object
Decide which system creates, updates, deactivates and resolves conflicts for items, barcodes, units, locations, prices, stock, lots, serials, orders and logistics labels.
Data dictionary and real samples
Record each field’s business definition, format, length, requiredness, example, source and target. Include Traditional Chinese, English, inactive, missing and unusually long test values.
What every barcode identifies
Confirm whether a code represents an item, pack, lot, serial, location, document, pallet, tote or carton. Record the symbology, data structure and treatment of alternate or legacy codes.
Scanner output and target field
List devices, operating systems, connection or output methods, character handling, prefix, suffix, Enter or Tab, and the target screen and field. Test production-equivalent equipment.
Label templates and printing ownership
Confirm media size, printer, resolution, deployment point, template version, data source, encoded values, visible text, print quantity, reprint and obsolete-label rules.
API, file or controlled import
Document the interface, stable external ID, create-or-update rule, validation, schedule, timeout, retry and reconciliation method. Replaying one event must not post stock twice.
Validation and exception routes
Define messages, owners, correction, approval, retry and audit records for unknown codes, missing data, duplicates, wrong locations, quantity variance, damage, outages and offline work.
Roles, permissions and devices
Separate view, post, override, adjust, reprint, maintain and approve rights. Include joiner, mover, leaver, lost-device and service-account procedures.
Representative and safe test data
Prepare production-like integrations, printers, scanners, user roles, masked records, expected balances and physical samples. Do not expose private customer or commercial data.
End-to-end acceptance scenarios
Link every normal and edge case to its expected source record, scan result, posting, status, label and interface response. Assign business testers and sign-off criteria.
Support and operational handover
Prepare SOPs, quick guides, configuration exports, mappings, label templates, monitoring, reconciliation, recovery, training, known issues and support escalation contacts.
Workflow mapping
The same item needs different fields in different transactions
An item code is only the starting point. Each scan must combine the relevant document, quantity, unit, location, status and traceability data to create a complete transaction.
| Workflow | Typical identifiers and fields to prepare | Key validation |
|---|---|---|
| Receiving | Purchase order or inbound reference, item, pack level, quantity, unit, lot or serial, status and receiving location | Correct document line and packaging conversion; no duplicate receipt |
| Putaway and movement | Work reference, item, source, destination, quantity, unit and pallet, tote or carton identity | Eligible location, correct warehouse and matching logistics-unit contents |
| Picking | Order or work, source stock, item, lot or serial, picked quantity, target handling unit and short reason | Prevent wrong item, location and duplicate posting; route shortages correctly |
| Packing and shipping | Shipment, container or SSCC, contents, quantity, serials, weight, carrier reference and completion status | Only eligible completed containers ship once and remain traceable |
| Stock count | Warehouse, location, item, lot or serial, counted quantity, unit, worker, variance reason and review status | Recount and approval rules; preserve original count and adjustment history |
| POS sale and return | Item or pack, transaction, quantity, unit, price source, tax configuration, payment and return reference | Price and tax come from the approved system; controlled return and void permissions |
Packing must validate the document, goods and label together
If a scan confirms only the item but not the shipment, container contents, quantity and status, the wrong goods may still proceed. Give each scan point an explicit success condition.
A POS barcode identifies the item; it should not set the price
After identification, price, discount, tax, membership and sale eligibility should come from approved POS or ERP rules. Avoid encoding frequently changing commercial data in a standard item barcode.
UAT and go-live acceptance
Do not test only whether a code scans; test whether the transaction is correct
Use the intended devices, labels, networks, user roles and safe production-like data to test both normal and exceptional outcomes before go-live.
Clean receipt and putaway
Start from the purchase order, scan the intended item, pack, quantity, lot or serial and destination, then confirm one receipt and the correct final on-hand position.
Unknown or ambiguous barcode
Test missing, inactive, wrong-pack and multiply mapped codes. The system should not guess or create uncontrolled master data; it should provide a safe next action.
Unit and quantity protection
Test each, inner-pack, carton and approved conversions. Invalid units, precision, over-receipt or over-pick should follow the agreed rules.
Lot, serial and date controls
Test missing, wrong, duplicated and malformed values. Require them only for the intended items and at the intended capture stage.
Wrong location and permissions
Try a valid location that does not match the work, a blocked location, and operator attempts to adjust, reprint or approve a variance.
Timeout, outage and retry
Interrupt the connection and restore it. The operator must know whether posting succeeded, retries must not duplicate it and failed events must remain visible.
Shipping tests should trace an order through to the parcel
Confirm that the order, shipment, container, parcel label and carrier reference can be reconciled. Partial shipment, blocked order and duplicate confirmation need defined outcomes.
Count tests must preserve variance and approval history
Test matches, variances, unexpected items, wrong lots and recounts. Any stock correction needs the correct approval and should retain the original count and reason.
Prepare for an enquiry
Share these details to define the barcode, device and system scope
Workflow and systems
- Current POS, ERP, WMS or inventory system and version
- Receiving, putaway, picking, packing, shipping, counting or retail flow
- Authoritative system for items, orders and inventory
Data and label samples
- Masked item, unit, location and order fields
- Supplier barcodes, current labels and print templates
- Lot, serial, date, carton or logistics-unit requirements
Devices and site conditions
- Scanner, mobile computer and printer models
- Interfaces, Wi-Fi coverage, working distance and locations
- Expected user roles, scan volume and exceptions
FAQ
Questions about WMS and ERP barcode data preparation
Should every product and transaction field be encoded in one barcode?
Usually not. Encode the identifiers needed by the scan workflow. Price, availability, order status, permissions and most business rules should be retrieved and validated by the POS, ERP or WMS.
Must an internal SKU and a GTIN be the same?
No. An internal SKU is the company’s item code, while a GTIN is a GS1 trade-item identifier. They may be cross-referenced, but should not be treated as one field without confirming allocation and packaging level.
Does every item need a lot, serial number or expiry date?
No. Use them according to traceability, quality, contractual and compliance requirements. A lot normally identifies a group; a serial identifies one instance. Date meanings must also be explicit.
Why do packaging units cause so many inventory errors?
The same item may be handled as each, inner pack or carton. If a code does not resolve to one pack level, a carton scan may be posted as one base unit. Define the base unit, pack quantities and permitted transaction units.
Does having an API mean the integration is ready?
No. You still need a field contract, stable external IDs, create-or-update rules, validation, authentication, retries, duplicate protection, an error queue, monitoring and reconciliation ownership.
How do we confirm scanner, printer and system compatibility?
Check exact models, operating systems, interfaces, drivers, application versions, barcode formats, labels and site conditions, then test the intended workflow. A brand name or the phrase “USB barcode support” is not enough.
Official references
Check identification standards and platform workflows
Planning a WMS or ERP barcode project?
Organise the data and workflow before choosing scanners, printers or integration methods
Share masked field samples, barcode and label photos, a workflow diagram, system versions and site-device details. Easy Scan can help clarify the next step based on the actual scope; final compatibility and service coverage must be confirmed against the systems, equipment and project requirements.
