Delivery Handheld Computers: From Scans to Proof of Delivery - Yenra

The DIAD example: a handheld within a larger system

UPS's Delivery Information Acquisition Device, or DIAD, illustrates how handheld computing became part of delivery operations. In its 2018 UPSNav announcement, UPS describes DIAD development beginning in 1991 and the use of the handheld display for purpose-built route guidance. Read that announcement as a dated account of the system at that stage.

The lasting design question is how a device fits the whole operation. A scan engine captures an identifier; a local application connects it to a stop or task; a communications link carries an event; and a back-end service makes the result available to other users. Navigation, route planning and proof of delivery may share the handheld while performing different jobs.

When comparing systems, ask to see one transaction all the way through. A radio connection or a successful scan alone leaves unanswered whether the correct parcel status reached the correct customer record.

Define the event before choosing the screen

GS1 describes EPCIS as a way to exchange event information about objects moving through business processes. Its dimensions—what happened to which object, when, where and in what business context—are useful questions even when an internal application uses a different format.

Scroll the table horizontally to see every column. Keyboard users can focus the table region and use the arrow keys.

This is a planning checklist, not an EPCIS schema. A production implementation needs defined field formats, validation, access controls and retention rules agreed with the service owner. Keep correction history so an investigator can distinguish an original observation from a later amendment.

Make pending work visible

A driver needs to know whether the action was captured, saved on the device, submitted or confirmed. Use distinct labels and a visible outstanding-work count. An unavailable connection should lead to a defined permitted offline action or a clear instruction to wait or contact dispatch.

Android's offline-first application guidance explains local data and synchronization strategies. For a delivery system, ask the supplier to demonstrate that permitted pending events survive application closure and device restart, then reach the server after reconnection. Define how long pending work may remain and who investigates it.

Network failures can happen after a server has accepted a request but before the device receives the acknowledgement. Retrying that request should preserve its original identity. The AWS Builders' Library discussion of idempotent APIs explains how request identifiers help make retries safe. Here, the practical goal is one accepted delivery event despite repeated transmission attempts.

Distinguish a retry from a new action. An unsuccessful delivery attempt followed by a later successful visit represents two business events for the same parcel. Deduplicating everything by parcel number would erase useful history. Agree how out-of-order arrivals and corrections affect the customer-visible state.

Decide what proof of delivery must establish

A photograph, signature or location reading is useful when its purpose and relationship to the event are defined. Establish which services require which evidence, what the worker does when it cannot be captured, and what the recipient or service team is entitled to see. Apply the organization's privacy and retention requirements to the exact operation.

Test evidence association explicitly. Capture a disposable image during one test delivery, start another parcel's task and verify that the first image remains attached to the correct event. Repeat after going offline. Confirm how an upload failure appears and whether the system distinguishes the event's confirmation from the evidence upload's completion.

Location data can add context, while the parcel scan and workflow validation establish other parts of the record. Design a clear exception for a location reading that is absent or unsuitable. The worker should be able to report the real condition without fabricating a value.

Set up route information and device mounting under the operator's approved vehicle procedures. Perform handheld data-entry tests while safely stationary. Battery replacement, charging and support commitments also belong in the hardware requirements assessment.

Test the visible result at every handoff

1. Load a small test route. Verify identifiers, stop details and allowed actions against prepared expected results.
2. Introduce a wrong parcel. Check the device's explanation and confirm that the back end remains correct.
3. Record both a success and an exception. Ensure the customer/service views distinguish them.
4. Lose connectivity. Save a permitted event, restart the application and verify the pending queue remains intact.
5. Reconnect and retry. Simulate a lost acknowledgement and confirm that one event stays one event.
6. Check the final views. Compare device state, server history, evidence, dispatch information and customer status. Record any propagation delay.

Measure capture failures, outstanding events, duplicate accepted events, evidence mismatches and the distribution of upload delays. Define targets for your service before the pilot. Averages alone can hide a small group of parcels with very long delays, so inspect those exceptions individually.

Download the delivery handheld acceptance checklist (plain text). For the underlying scan-validation and application integration choices, continue with industrial handheld data capture.