A completed pick does not prove that every item entered the intended carton or that the carton carries the right shipping label. Packing verification adds a controlled relationship between the shipment, the physical carton, its contents and the label that will travel with it. The useful result is not merely a series of successful decodes; it is a closed carton whose recorded contents and outward identity agree with the approved dispatch task.
The scenario below is an editorial construction, not a customer deployment or an AIDC GO device test. The handheld-terminal category, warehousing and logistics page, mobile barcode data-capture solution and Integration Support are commercial starting points. Packing rules, carrier connections and WMS behavior must be confirmed for the actual project.
Keep the identifiers and states separate
An order identifies the commercial demand. A shipment record groups the inventory that the warehouse plans to dispatch. A reusable tote may carry picked goods to the packing area, while a shipping carton is the physical package sent outward. A carrier tracking number identifies a transport label or parcel in the carrier workflow. These identifiers can be related, but scanning one must not silently substitute for another.
The application should make the active context visible before items are committed: shipment or order, packing location, open carton ID, expected item and unit, packed quantity and label status. The picking-verification guide covers the preceding source-location, item and order-tote checks. Packing begins from that controlled handoff and answers a different question: which physical carton now contains each confirmed unit?
Microsoft's Pack containers for shipment documentation describes a bounded Dynamics 365 Supply Chain Management process in which workers validate item quantities and types, assign items to containers, close containers and move them toward outbound shipping. Its configurable policies can separate closing from release. Those are named product behaviors, not universal WMS states and not functions supplied by a scanner alone.
Follow one two-order packing example
Assume two editorial orders at one packing area. Order SO-481 requires six units of item FILTER-A and will ship in two cartons: four units in CTN-481-1 and two in CTN-481-2. Order SO-482 requires four units of the visually similar item FILTER-B in CTN-482-1. The packer selects shipment task SHP-481, creates or selects CTN-481-1, and confirms the carton ID before scanning contents.
Four FILTER-A units are accepted into CTN-481-1. The system shows the carton content as four of six for the shipment, while the remaining two units stay unpacked. The packer closes that carton, opens CTN-481-2, packs the remaining two, and closes it. Only after both carton records are complete does the workflow permit the shipment's release step under this editorial rule.
If a FILTER-B code is scanned while CTN-481-1 is active, a good exception screen preserves the scanned value, expected value, active carton and order rather than replacing the item to make it pass. If a correct FILTER-A unit is scanned while CTN-482-1 is active, the item identity is still wrong for that order. A correct product placed in the wrong carton is a packing error even though the barcode decoded correctly.
The saved record should identify the operator or system actor, item, quantity, unit, source task, carton, time, exception decision and final carton state. The quantity-and-unit guide explains why a decode must not imply one piece when the project's pack, case or each conversion says otherwise.
Make shortages, overages and repacking visible
A missing unit should remain an open packing difference, not be hidden by closing the carton at the expected quantity. An extra or unlisted item should be held for investigation before it changes the shipment record. When one scan represents a sealed case, the application must use the approved unit relationship and carton contents rule; it should not multiply quantities from an operator assumption.
Repeated scanner output and a deliberate second unit are also different events. Scanner-side duplicate suppression can reduce accidental repeats, but the packing transaction must decide whether the same identifier is permitted again. The duplicate-read guide covers the capture behavior; the WMS or packing application still owns the carton-content rule.
If a closed carton must be reopened, record who reopened it, what was removed or added, and which later checks became invalid. Moving an item from CTN-481-1 to CTN-481-2 should create a transfer in the packing history rather than leaving both cartons claiming the same unit. After repacking, recalculate or re-enter project-required weight and dimensions and repeat any label or release checks that depend on the changed carton.
Bind the printed label to the carton record
Printing a label and applying the correct label are separate steps. Before release, scan the physical carton ID and the newly applied shipping label, then compare the label's shipment, parcel or tracking reference with the active carton record. Do not infer the order from label position on the bench. If the project uses a carrier tracking number, store the returned number against the intended carton and verify the actual printed symbol can be read back.
For a reprint, the application should show whether the old tracking number remains valid, is voided, or is replaced. Remove or visibly invalidate obsolete labels according to the carrier and warehouse procedure so two readable outward labels do not compete. A second print command is not evidence that the first label was destroyed or that the replacement reached the correct carton.
Microsoft's Warehouse Management mobile app packing documentation identifies specific configured menu items for packing, carton creation, closing and label printing. It also states that packing behavior depends on associated mobile-device container packing policies, and that container-line packing details require Supply Chain Management version 10.0.45 or later. These boundaries are why an integrator must verify the actual product version and configuration instead of promising the same flow for every handheld application.
Do not collapse outbound milestones
Pick complete, contents confirmed, carton closed, released for shipment, and carrier accepted should remain distinct milestones. A container policy may release a carton automatically, later, or optionally in the cited Microsoft example. Another WMS may use different states. The project should document what each state permits and which actor or integration can advance it.
Closing CTN-481-1 establishes the recorded carton contents under the configured rule. It does not prove that the carton is on the correct pallet, that the shipment is manifested, that the carrier has collected it or that a delivery occurred. Likewise, a tracking number can exist before the carrier accepts the parcel. Customer-facing status should be driven by the appropriate event rather than by the earliest convenient scan.
If the application loses its response after a close or release request, query the original operation or carton identity before resubmitting it. The offline transaction guide explains how to keep an uncertain result from becoming a duplicate business action.
Test the packing chain with real labels and exceptions
Acceptance should use the actual item labels, carton labels, printers, packing surfaces, units and application version. Run a correct single-carton order and a split shipment, then deliberately present a wrong item, wrong carton, short quantity, extra quantity, repeated scan, unreadable label, reprint and reopen/repack case. Verify server records, not only the beep or screen color.
Check that the display keeps the active order, shipment and carton visible, that a nearby barcode is not silently selected, and that the packer can recover from a damaged symbol without bypassing the business rule. Read back a sample shipping label after application, and confirm that old labels are handled by the documented carrier and warehouse procedure.
For procurement, ask for the exact scan interface, supported symbologies, label-print path, offline behavior and WMS version used in the acceptance test. No AIDC GO WMS, carrier integration, automatic packing decision or error-rate improvement is implied. To review the hardware and integration boundary for a real packing workflow, use Contact AIDC GO.