A receiving scan loses its network confirmation. Should the worker wait, submit again or ask someone to check the WMS?
The answer depends on where the operation stopped. A receipt saved locally before its first send is different from a receipt the warehouse management system may already have accepted. A timeout alone cannot distinguish them. The application needs to preserve the operation's identity, show what is actually known and follow an agreed way to recover its result.
This guide assumes the barcode was decoded, its fields were parsed and the receiving request was constructed correctly. If the values themselves are wrong, start with GS1 barcode parsing and WMS data mismatches.
1. Where did confirmation stop?
Consider one receiving operation. In this illustration, the project allows the application to save a pending receiving intent while offline. That permission does not mean authoritative inventory has changed or that the worker may move or release the goods.
This is an editorial illustration, not a customer case or a tested AIDC GO implementation. The server outcomes below are stipulated to explain the difference; the operator does not automatically know them.
| Situation and actual sequence | What the application can establish | Recovery question |
|---|---|---|
| Normal completion: intent saved → request sent → WMS gives final business acceptance → confirmation received and recorded locally. | A correlated business result supports “Confirmed accepted.” | Does that result authorize the worker's next action? |
| Before first send: intent saved → connection unavailable before any sending begins. This example excludes another sender. | Reliable records support “Saved locally — pending send.” An offline icon alone does not. | How will the original pending operation be sent and confirmed when sending is permitted? |
| Confirmation lost: request sent → WMS accepts the receipt → response fails to reach the application. | The application knows it attempted submission but lacks the outcome: “Outcome unconfirmed.” | Can it recover the specific result through a supported query or safe replay of the same operation? |
In the third example, the WMS did accept the receipt. In a real timeout, that remains a question until evidence resolves it. Reporting “Not submitted” can invite a second receipt; reporting “Completed” can authorize work without confirmation.
2. What does the status actually confirm?
Use status language that separates these facts:
- Captured: the application has the scan data.
- Saved locally: the application has confirmed a local write.
- Send attempted: a sending attempt began; the business outcome may remain unknown.
- Accepted for processing: the backend admitted work, if the interface has this intermediate state.
- Business accepted: the WMS reached the final acceptance defined for this receiving operation.
- Confirmation recorded: the application received the corresponding result and saved its updated state.
These are distinctions to evaluate, not prescribed API state names. Define which evidence supports each displayed status and which actions remain available to the worker.
HTTP 202 Accepted means processing has been accepted but is not complete. It does not establish that inventory was posted. Read the documented business result rather than treating a transport response as the receipt's final outcome. RFC 9110, Section 15.3.3
An offline interface also needs a write policy. Android's offline-first guidance distinguishes applications that require connectivity for writes from those that save writes locally. Offline reading capability does not imply permission or support for offline receiving. That guidance describes application architecture, not the capabilities of an AIDC GO model. Android Developers: Build an offline-first app
If saving fails, “Queued” is not an accurate status. If confirmation arrives but its local update fails, the server may have accepted the receipt while the application still needs to recover that result.
3. What must remain identifiable after an application restart?
Ask the application team to show how it can recover one pending receipt after a restart. A useful review record connects:
- The logical operation identity and receiving context, such as the document and line.
- The original intended action and its controlled request content or version.
- Each sending attempt and its relationship to that operation.
- The latest established state and any corresponding backend receipt or result reference.
Field names, storage design, access controls and retention periods belong to the project. The practical requirement is to recover enough evidence to distinguish the old operation from a new one.
A barcode identifies data on the label; it does not necessarily identify one receiving action. Two legitimate receipts may contain the same barcode. Similarly, an attempt reference or tracing reference does not automatically serve as the operation's deduplication identity.
A restart can also expose a gap between sending and recording that sending occurred. If the application cannot establish whether the request left, it should preserve the uncertainty. Restoring an empty in-memory queue is not proof that nothing reached the WMS.
4. How can the team find the WMS outcome?
Identify the supported recovery channel before allowing workers to resolve an unconfirmed receipt. It might be an operation query, a business receipt lookup, an existing status reference or a documented replay mechanism.
Microsoft's asynchronous request-reply pattern illustrates why a status resource matters: acceptance and completion are separate, and a successful HTTP 200 status query may still report pending work. This is an architecture pattern, not evidence that a particular WMS provides such an interface. Microsoft Azure Architecture Center: Asynchronous Request-Reply pattern
For the receiving workflow, ask three concrete questions:
- If the first response containing the result reference is lost, how can the original operation be found?
- Does the recovered result identify this receipt and distinguish processing, final rejection and final acceptance?
- If no result is found, what does that absence mean under the service's visibility and retention rules?
A missing record or 404 response may reflect an incorrect reference, restricted visibility or an expired record. Treating it as proof of non-processing requires an explicit service guarantee. An inventory balance change is also insufficient to identify this particular operation; another receipt may have changed the balance.
There is no universal rule that a query must always precede a retry. Use the recovery method the interface supports. If neither querying nor safe replay is available, define a backend review path and what the worker may do while waiting. Deleting a local pending item does not undo a receipt already accepted by the WMS.
5. What makes a retry the same receipt?
An idempotency contract defines how repeated requests for one operation are handled without repeating its intended business effect. Sending a stable identifier is only part of that arrangement.
On the client side, preserve the logical operation identity and intended action across attempts. On the server side, verify how identity is scoped, how changed parameters and concurrent requests are handled, and how long recognition remains valid. The relationship between the deduplication record and business changes also matters. Amazon's idempotent API discussion explains these conditions and the problems posed by late requests or reused identifiers with different intent. Amazon Builders' Library: Making retries safe with idempotent APIs
Apply those questions to the complete receiving path. If middleware recognizes the operation but sends work to a WMS, ask where duplicate processing is prevented downstream. A cached middleware response alone does not establish that the WMS cannot receive the action twice.
Automatic retries also need justified semantics. HTTP does not generally permit a client to automatically retry a non-idempotent request merely because confirmation was lost; it needs knowledge that retry semantics are safe or that the original request was not applied. RFC 9110, Section 9.2.2
Specify retryable outcomes, timing and limits with the API owner. Authentication failures, changed quantities and business rejections need their own handling. If the recognition window expires or the intended receipt changes, follow the agreed reconciliation or correction process. Silently assigning a fresh identity can turn unresolved work into a second receipt.
6. Which failure cases should the project test?
Use an authorized test environment and constructed receiving data. The following are proposed tests, not executed results. For each case, agree the expected business outcome with the application, middleware, WMS and operations owners before injecting the fault.
| Test point | Evidence to compare | Acceptance question |
|---|---|---|
| Normal completion as a control. | Operation identity, submitted intent, WMS result and recorded application state. | What proves final acceptance and permits the next warehouse action? |
| Disconnect after local saving but before the first send; then restore connectivity. | Saved intent, first sending attempt and resulting business receipt. | Does the application retain the original pending operation and report its eventual result? |
| Drop the response after independently confirming server acceptance. | Server receipt alongside the application's unconfirmed state. | Can the original outcome be recovered without creating a second receiving action? |
| Combine repeated submit clicks with automatic retry; separately test unstable connectivity with concurrent senders. | Clicks, attempts, operation identities and server effects. | Are repeated attempts distinguished from a genuinely new receipt? |
| Restart before sending; repeat after sending but before confirmation. | Records and identities before and after each restart. | Does recovery preserve the operation and any uncertainty about sending? |
| Fail the initial local save; separately fail the local update after confirmation arrives. | Storage results, displayed status and, for the second case, the server receipt. | Are unsupported “Saved” claims avoided, and can an accepted outcome be recovered? |
| Change quantity or document line under the same identity; separately exceed the documented recognition window. | Request versions, service responses and retained result records. | Does the agreed exception process apply without silently substituting a new identity? |
Also agree who resolves a closed receiving document, changed user permissions or related work completed on another terminal. Connectivity returning does not decide those business conflicts. Put this focused evidence into the wider AIDC Pilot Validation Checklist.
7. Frequently asked questions
Does a successful scan mean the receipt reached the WMS?
No. It establishes a capture result. Sending, business acceptance and recording the corresponding confirmation require separate evidence.
Should an unconfirmed receipt be retried with a new ID?
Do not use a new identity simply to escape an unknown outcome. First follow the recovery contract for the original operation; a new identity may represent an additional receipt.
Does the same barcode or request ID prevent every duplicate?
No. A barcode can occur in separate legitimate operations. A request identifier helps only when the relevant services implement and honor the required identity, scope and processing rules.
What if the application restarts before confirmation returns?
Recover the original pending operation and its known state. If sending may already have occurred, use the supported result-recovery path. Restarting alone provides no evidence that the WMS rejected or forgot the receipt.
8. What should be agreed before accepting the workflow?
Name who owns pending-operation recovery, where its result can be checked, and when operations staff must intervene. Define the worker's permitted actions while a receipt is pending or unconfirmed. Record these decisions in the AIDC Device Integration Checklist, then include the agreed exception procedure in deployment readiness.
AIDC GO can discuss hardware direction, model-specific configuration documentation and sample coordination through Integration & Support. Bring the input, display, network and power conditions needed to evaluate your application on the proposed configuration. The customer application, middleware and WMS teams remain responsible for local saving, retry behavior, business rules and final acceptance.
To discuss your application, prepare one shareable receiving flow: the interruption point, the worker's visible status, sanitized operation references, the available backend result and the expected next action. That gives the teams a concrete basis for evaluating the hardware and application together.