Hong Kong ecommerce fulfilment workflow guide
Ecommerce Fulfilment Workflow: WMS, Printers and Inventory Sync
A controlled ecommerce fulfilment workflow preserves the channel order and line identities from import, validation and hold through allocation, reservation, pick task, item/location/quantity scan, pack verification, label generation, carrier manifest and handoff, dispatch confirmation, inventory and status update, then cancellation, return and exception review. Reserved or committed stock is not the same as physically available or picked stock, and an asynchronous connector update is not a promise of real-time inventory or zero overselling.
Fulfilment connects order identity, physical handling and exception control
The commerce platform, ERP, WMS, shipping application and carrier may each own different states. Define those boundaries before choosing a scanner, PDA or printer. Link to the detailed WMS, picking/packing and shipping-label workflows instead of duplicating their operating rules here.
Separate order, line, stock, carton, shipment and connector states
Import → validate → reserve → pick → pack → label → handoff → update → reconcile
Progress from desktop scan to mobile tasks and WMS when control signals require it
Choose one owner for each order, line, location, stock, carton and shipment state. Release work only after validation, scan what was actually picked and packed, let the source system acknowledge dispatch and inventory updates, and keep delayed, rejected or conflicting operations visible.
Order, line, item and shipment identity
Keep every imported order line traceable to its physical fulfilment result
One customer order can contain several lines, locations, cartons or partial shipments. Preserve the channel order ID, source line ID, SKU or inventory-item ID, assigned location, pick task, tote/carton and fulfilment or shipment ID as separate fields. A generic reference field cannot safely replace those relationships.
| Identity | What it controls | Warehouse evidence | Common mistake |
|---|---|---|---|
| Channel order | Customer transaction and source status | Current version, payment/hold and cancellation state | Releasing an order still on hold |
| Order line | Item, requested quantity and line-level status | Source line ID, SKU and fulfillable quantity | Updating the whole order for one line |
| Inventory item/location | Which stock record and site may supply the line | Item master, location and eligible state | Mixing shared-stock locations |
| Pick task/tote | Who should collect which item and quantity | Task, user, source and destination | Scanning an item outside the active task |
| Carton/shipment | What physical package will leave | Pack result, carton and carrier/service state | One label closing every split line |
Available, reserved and physical stock
Reservation is a system commitment, not proof that the item is on the picker’s cart
On-hand, available, committed or reserved, safety stock, quality hold, damaged, picked, packed and shipped can be different states. Define which quantities the channel may sell and which source has authority to change them. Shared-stock conflicts remain possible when channel timing, reservations and physical handling diverge.
| State | Meaning to define | Control question |
|---|---|---|
| On hand | Physical quantity recorded at a location | Does it include damaged, held or unavailable stock? |
| Available | Quantity currently offered for new demand | Which safety and channel rules reduce it? |
| Reserved/committed | Quantity assigned or held for an order | Can the physical item still be missing or mislocated? |
| Picked | Actual quantity collected under a task | Was item, location and unit confirmed? |
| Packed | Actual quantity verified in a carton | Were shortages and substitutions recorded? |
| Shipped/returned | Quantity that changed custody or came back | Which accepted event changes the source stock? |
Operating stages without arbitrary volume thresholds
Upgrade when visibility and exception control break; avoid fixed order-count thresholds
A spreadsheet and desktop scan can remain workable for a controlled single location with clear ownership. Mobile computers help when work moves and staff need tasks, quantities and exceptions on screen. A WMS becomes relevant when routing, locations, shared stock, queues and controls can no longer remain dependable in the simpler setup.
| Stage | Suitable starting point | Control limit to watch | Next signal |
|---|---|---|---|
| Spreadsheet/manual list plus desktop scan | Stable item list, one controlled area and a named operator | Copy/paste, stale lists, shared files and manual status updates | Duplicate entry or exceptions no longer reconcile visibly |
| Desktop application plus scanner/printer | Bench-led pick/pack or order review with host-owned logic | Worker must return to the station for task and exception context | Moving work and location confirmation dominate |
| Mobile computer/PDA | Screen-led pick, quantity, location and exception work on the move | App, network, permissions and charging remain required | Routing, shared inventory and queues need central orchestration |
| WMS/integrated fulfilment layer | Multi-location, multi-channel or 3PL control needing structured tasks | Configuration, connectors and data ownership still need validation | Scale only after pilot states and exceptions are accepted |
For broader stock and location planning, see Inventory and Warehouse Management. When moving tasks need a screen, scanning and exception input, use the Mobile Computer Selection for Logistics guide.
End-to-end ecommerce fulfilment flow
Eleven control points connect a channel order to dispatch and reconciliation
Platform terminology differs, but order, line, stock, physical item and source response should remain connected.
| Step | Action | Control evidence | Stop condition |
|---|---|---|---|
| 1. Import order | Capture channel order and line identities | Source, version and connector reference | Duplicate or incomplete import |
| 2. Validate/hold | Check payment, address, item, fraud/business rule and cancellation | Released or named hold state | Unresolved hold |
| 3. Allocate/reserve | Assign eligible location and stock state | Location, line quantity and reservation response | Shortage or conflicting commitment |
| 4. Create pick task | Release lines to a user, zone, tote or batch | Task ID, route and priority | Superseded or unassigned work |
| 5. Scan item/location/quantity | Confirm what was actually collected | Item, source, unit and actual quantity | Wrong, short or unknown scan |
| 6. Verify pack | Match items and quantities to the carton | Carton identity and pack-complete result | Missing, extra, damaged or mixed order |
| 7. Generate label | Use the current shipment data and approved template | Label, service and printer response | Wrong, stale or duplicate output |
| 8. Manifest/handover | Close eligible carrier group and transfer custody | Manifest and physical handoff state | Open exception or carrier rejection |
| 9. Confirm dispatch | Mark only accepted shipped cartons | Carton/shipment and source reference | Print success alone |
| 10. Update inventory/status | Send accepted changes to source systems | Sent, acknowledged, rejected or conflicted state | Unknown connector outcome |
| 11. Review cancellation/return/exception | Reconcile physical custody, order and stock | Reason, owner and accepted correction | Silent overwrite or assumed refund |
Pick tasks and grouped-order separation
Preserve line and tote identity when orders share a pick route
Grouped or batch picking can improve movement only when each scan stays linked to the correct task, line, tote and quantity. Record short picks, substitutions and unknown barcodes visibly. This article keeps the detailed route, tote and pack-station design in the dedicated picking/packing guide.
Pack verification
Confirm actual contents and carton identity before creating the final shipment output
At the bench, scan or select the order, carton and expected items; compare actual quantity, damage, lot or serial where required and any split/partial result. One order may produce several cartons or shipments. Keep remaining quantities open instead of marking the whole order fulfilled after the first carton.
| Case | Order-line control | Customer/source update boundary |
|---|---|---|
| Complete shipment | All released lines and quantities packed | Confirm only after the accepted dispatch event |
| Split cartons | Each carton retains its lines and quantities | Separate labels and shipment references where required |
| Partial shipment | Shipped and remaining quantities stay distinct | Validate whether the channel supports partial status correctly |
| Short pick | Actual picked quantity and reason recorded | Do not reduce or cancel demand silently |
| Substitution | Only under an approved item and customer rule | Update item, price and communication owners as configured |
Label and printer boundary
Generate the shipping label after pack validation from the current shipment state
Define which application owns the carrier label, internal carton label and any standards-based logistics label. Route to the intended desktop or industrial printer, control template version, media and reprints, then scan the carton-label pair where required. A printed label does not prove carrier acceptance.
The Shipping solution page outlines the wider outbound equipment and workflow context. Confirm label identity, print quality, placement, void and reprint rules during implementation.
Manifest, carrier handoff and dispatch
Separate label creation, manifest closure, physical handoff and carrier acceptance
Manifest rules can depend on carrier, warehouse/account and ship date. Keep cancelled labels and open exceptions outside the wrong close-out group. Confirm dispatch from the event accepted by the selected workflow, not from a printer message or an assumed collection.
Asynchronous integration and queue visibility
Show pending, retried, accepted, rejected and conflicted updates separately
Order routing, webhooks, polling, connector retries and carrier responses can all create delay. Treat asynchronous operation as normal unless the exact integration proves otherwise. Staff should see the last trusted source state, the local warehouse result and the connector operation status.
| State | Meaning | Required handling |
|---|---|---|
| Pending/local | Warehouse event not yet acknowledged centrally | Keep operation ID, object, time and owner |
| Queued/retrying | Connector is waiting or resubmitting | Use stable references and visible retry policy |
| Accepted | Source acknowledged the intended update | Store response and resulting source version |
| Rejected | Source did not accept the update | Show reason and preserve the physical result |
| Conflict | Newer cancellation, stock or status exists | Apply a named resolution or supervisor review |
| Unknown | Outcome cannot be established | Do not assume success or resubmit blindly |
No zero-overselling promise
Reservations, safety stock and quicker updates can reduce exposure, but overselling can still occur when channels, shared stock, cancellations and physical handling are out of alignment. Validate the actual connector and inventory-state model.
Cancellation, returns and reverse logistics
Cancellation request, stopped warehouse work, received return and refund are different states
A channel cancellation can arrive after picking or label generation, and a request does not guarantee that the parcel stopped moving. For returns, identify the order, line, item and quantity; inspect condition; choose quarantine, return-to-stock or another disposition; then post inventory and refund-related states only under the configured owners.
| State | Physical question | System question |
|---|---|---|
| Cancellation requested | Has warehouse work started or custody changed? | Which system may accept or reject it? |
| Cancellation accepted | Where are picked goods and labels? | Which reservation and order state reverses? |
| Return initiated | Has the item actually arrived? | Is a portal or return reference open? |
| Return received/inspected | What item, quantity and condition came back? | Which disposition changes stock? |
| Refund/adjustment | Does physical receipt satisfy the policy? | Which channel/payment owner confirms money status? |
3PL owner and account boundaries
Separate client, inventory owner, account, location and reporting scope where the platform supports it
A 3PL operation may need client-specific order visibility, stock ownership, label accounts, carrier billing references, exception permissions and reports. Confirm which fields and access controls are genuinely configurable in the chosen WMS or 3PL platform. Do not infer client billing, portal or reporting functionality from a generic warehouse workflow.
- Keep client/owner and physical location as separate dimensions.
- Route orders and inventory only within the confirmed account rules.
- Restrict who can view, adjust, cancel, relabel and release each client order.
- Preserve client-specific references through shipment, return and exception records.
- Validate reports against source transactions rather than assuming a generic dashboard provides them.
Scaling and WMS upgrade signals
Look for loss of control rather than a fixed daily-order threshold
- Multi-channel duplicate entry: staff rekey the same order, line or address across systems.
- Shared-stock conflict: two channels or clients claim the same physical quantity.
- Repeated relabelling: stale, wrong-service or client/account labels require manual replacement.
- Weak traceability: the team cannot explain who picked, packed, changed or dispatched a line.
- Opaque queues: pending, rejected and retried connector operations are invisible.
- Uncontrolled exceptions: short picks, splits, cancellations and returns rely on personal messages or spreadsheets.
- Location ambiguity: available stock cannot be tied to a trusted physical location or owner.
- Client reporting gaps: 3PL data must be rebuilt manually from unrelated files.
Common mistakes
Fast order import can still produce wrong stock and shipment states
- Using order number as every identity. Lines, cartons, shipments and returns lose their relationships.
- Treating reservation as physical stock. Missing or mislocated items appear ready.
- Marking complete at first partial shipment. Remaining demand disappears from view.
- Printing before pack verification. Changes create stale or competing labels.
- Calling a connector real time. Background routing and retries still create delay.
- Retrying unknown updates blindly. Duplicate dispatch or inventory posts can result.
- Combining cancellation, return and refund. Physical custody and money status become misleading.
- Buying a WMS before mapping exceptions. Unclear ownership is reproduced in the new system.
Decision and pilot checklist
Validate one channel-to-dispatch route before expanding locations or clients
- Map order, line, SKU, inventory item, location, task, tote/carton, shipment and label IDs.
- Define available, reserved, picked, packed, shipped, cancelled and returned stock states.
- Name the source of truth and owner for every state change.
- Choose desktop scan, mobile computer and WMS roles by workflow, not arbitrary volume.
- Test normal, held, short, split, partial, cancelled, damaged and return cases.
- Validate item, location, quantity and carton scans with actual pack configurations.
- Confirm label, printer, manifest, handoff and void boundaries by carrier workflow.
- Test delayed, retried, rejected, duplicate, out-of-order and conflicting connector updates.
- For 3PL, validate client, owner, account, location, permission and report boundaries.
- Compare the physical result, source order, inventory and customer-facing status before rollout.
Acceptance tests
Approve observable order, stock and shipment states without fake metrics
| Test | Pass evidence | Failure route |
|---|---|---|
| Import/duplicate control | Each source order and line maps once to the intended objects | Hold duplicate or incomplete import |
| Reservation/short pick | Reserved, actual picked and remaining quantities stay distinct | Release exception for review |
| Item/location/quantity scan | Wrong inputs are rejected visibly under the active task | Keep task open |
| Pack/split/partial | Each carton retains its lines; remaining quantity stays actionable | Block completion |
| Label/handoff | Current label and eligible shipment enter the correct manifest/handover | Quarantine carton |
| Async update | Pending, accepted, rejected, conflict and unknown states are distinguishable | Supervisor resolves source state |
| Cancellation/return | Physical custody, stock, order and refund owners remain separate | Do not assume reversal |
| 3PL separation | Configured client, owner, account and permission boundaries hold | Stop cross-client release |
| Recovery | Restart or reconnect does not create an unintended second post | Reconcile operations before retry |
Frequently asked questions
Ecommerce fulfilment workflow FAQ
Is reserved stock the same as stock ready to ship?
No. Reservation is a system commitment. The physical item may still be missing, held, damaged, mislocated or not yet picked and packed.
Can inventory synchronize in real time across every ecommerce channel?
No universal real-time behaviour should be promised. Routing, webhooks, polling, retries and channel rules create delay; validate the exact connector set and expose pending or failed states.
Does this workflow prevent overselling completely?
No. Reservations, safety stock and faster updates can reduce risk, but shared-stock conflicts, delayed channels, cancellations and physical errors can still create overselling.
When should a business move from spreadsheets to a PDA or WMS?
Move when duplicate entry, location ambiguity, opaque queues, shared-stock conflict or uncontrolled exceptions make the simpler workflow unreliable. There is no honest universal order-volume threshold.
How should split or partial shipments be handled?
Keep each carton or shipment linked to its exact lines and quantities, keep remaining demand open, and test whether each selling channel can represent partial fulfilment correctly.
Does printing a carrier label complete the order?
No. Pack verification, label creation, manifest, carrier handoff, source dispatch confirmation and customer status are separate states.
What must a 3PL separate for different clients?
Where the selected platform supports it, confirm client or inventory owner, account, location, permissions, label/carrier references, exceptions and reporting scope. Do not assume unverified portal or billing features.
How should returns change inventory?
First identify and inspect the actual returned line and quantity, then apply an approved disposition such as quarantine or return to stock. Refund and stock updates may have different owners and timing.
Map the states before selecting the stack
Bring your channels, stock rules, pick/pack route, labels and connector exceptions to a practical review
Easy Scan can help review desktop and mobile device roles, WMS upgrade signals, printer checkpoints, inventory states, 3PL boundaries and pilot acceptance cases. Final connector, platform and carrier behaviour depends on the selected systems and configuration.
