Case study

Barcode picking without touching the SDK — Zebra TC21, DataWedge profiles, 3PL warehouse

A 3PL warehouse needed barcode picking against ERPNext without maintaining custom scanner SDK code. DataWedge profiles on Zebra TC21 handhelds turn scans into keystrokes straight into the picking screen, provisioned centrally across the fleet.

A third-party logistics warehouse running Zebra TC21 handhelds needed barcode picking against ERPNext, their existing warehouse management system, without taking on the ongoing cost of maintaining a custom Android app against Zebra's scanner SDK. The picking workflow itself — scan a location barcode, scan an item barcode, confirm quantity — didn't need a bespoke UI; ERPNext's own mobile-friendly picking screens already existed and worked in a browser.

The brief was narrower than a typical SDK integration: make barcode scans land in ERPNext's existing web-based picking forms as if they were typed, reliably, across a fleet of handhelds that IT wanted to provision centrally rather than configure one at a time.

The problem

Writing a custom Android app against Zebra's scanner SDK would have worked, but it commits the client to maintaining that app indefinitely — SDK version bumps, Android OS upgrades, a codebase that outlives the person who wrote it. Zebra's DataWedge is built for exactly this case: it can turn a scan into simulated keystrokes injected into whatever app has focus, which means a browser-based ERPNext picking form can receive scan input with zero app code, provided the DataWedge profile is configured correctly and consistently.

The catch is "configured correctly and consistently" across a fleet. A DataWedge profile is per-device configuration; done by hand on each unit, it drifts — one device gets updated, twelve don't, and picking behavior becomes inconsistent in ways that are hard to diagnose because nothing crashes, a barcode just intermittently produces the wrong keystroke sequence (a stray Tab or Enter placement is enough to misalign a form field).

Hardware used

Architecture

The DataWedge profile is scoped to the browser app used for ERPNext, so scans only inject when that app has focus — the same reasoning as scoping any input listener, just done through configuration instead of code. The profile defines the keystroke suffix (Tab vs. Enter) per field type, matched to how the ERPNext picking form actually advances focus between location, item, and quantity fields.

Copy[Barcode scan trigger]
        |
        v
   [DataWedge profile, scoped to ERPNext browser app]
        |
        | decode -> keystroke sequence (barcode + suffix key)
        v
   [ERPNext picking form, browser, focused field]
        |
        v
[Field auto-advances: location -> item -> quantity]
        |
        v
[StageNow profile package] --pushed fleet-wide, no per-device manual setup--

Rather than configuring each TC21 individually, the profile was built once and packaged as a StageNow configuration — a provisioning file that can be applied to a device via barcode scan or MDM push, so a new or reset handheld gets the identical profile in one step instead of a technician manually walking through DataWedge's settings screens.

What was tricky

The keystroke suffix mismatch was the recurring bug class, and it's a genuinely fiddly thing to get right because the correct suffix depends on exactly how the target web form is built, not on anything DataWedge exposes cleanly. ERPNext's picking form advances focus differently depending on field type — quantity fields needed an Enter to commit and advance, while the location and item fields needed a Tab, and getting this wrong doesn't throw an error, it just types the next barcode into the wrong field silently. This was diagnosed almost entirely by watching pickers in person, because the failure looked like "sometimes the form is wrong" with no clear pattern until it was tied to field type specifically.

The other issue was that centralizing provisioning solved the drift problem but created a new single point of failure — a mistake in the StageNow package now propagates to every device at once instead of one. That risk was handled by staging profile updates through a small subset of devices first before fleet-wide push, which is a process discipline more than a technical fix, but it's the part that actually prevented a bad profile update from taking down picking fleet-wide during a later revision.

Result

Picking now works entirely through ERPNext's existing browser-based forms with no custom Android app to maintain, and new or replacement handhelds are provisioned in under two minutes via a single StageNow scan instead of manual per-device configuration. Field-misalignment mis-scans, which were the dominant complaint during the pilot phase, dropped to a handful of edge cases after the per-field-type suffix fix, down from a daily occurrence.