Inbound operations answer several questions: what is expected, what arrived, what was counted,
and where usable stock is stored. Keep those facts separate when connecting a warehouse or
building an agent workflow.
Start with the warehouse receiving quickstart. Its complete
Node SDK 1.35.1 program verifies partial receipts, rejection of excess quantities, cancellation,
and the boundary between received quantities and inventory on hand.
1 — Track the inbound shipment
An inbound shipment records a supplier and expected product lines. The quickstart creates the
supplier and product first and uses their returned IDs. It then moves the shipment through
pending, in_transit, and arrived before recording quantities against a shipment line.
For HTTP integrations, consult create inbound shipment
and receive a line.
These use their own request shapes. The HTTP contract requires a deployed commerce service;
use the local quickstart if you do not have one, and check the API directory
for setup rather than assuming a public commerce host.
2 — Receive against a receipt
Choose the record family used by your integration before sending quantities:
These are separate accessors and record IDs. An inbound shipment line is not a warehouse receipt
item. The Node SDK 1.35.1 Receiving class does not expose every operation in the HTTP receiving
contract; for example, its published declaration has no receipt-line receiving method. Check
binding coverage before planning the rest of the workflow.
The HTTP receiving reference documents receipt
creation, and the line-receiving endpoint
documents that service’s input. Do not substitute an inbound shipment ID for a receipt ID or
copy the embedded argument shape into an HTTP request.
In the tested Node inbound-shipment workflow, recording all expected units changes the
shipment to received but leaves inventory on hand unchanged. A successful receipt call
is not sufficient evidence that stock is available for orders.
3 — Put away
Put-away tracks the move from receiving to a storage location. If your deployment uses the
HTTP put-away workflow, follow its creation contract
and completion contract, using
the receipt and location identities returned by your system.
Before calling a warehouse operation complete, verify the counted quantity, the location
assignment, and the resulting inventory in the system that owns sellable stock. If those
records live in different services, retain their mapping and the integration job’s outcome.
The connection guide provides a template for that mapping.
Do not promise automatic stock posting, supplier-bill matching, or downstream notifications
from a shipment state alone. Test the behavior of your selected receipt or put-away operation
and the integration that propagates it.
When the count is wrong
A receiving discrepancy and an inventory correction are different events. Record what was
counted, retain the expected quantity for comparison, and let the configured process resolve
missing, damaged, or excess units.
For an explicit stock correction, the inventory quickstart
demonstrates a signed adjustment with a reason and a read-back of the resulting stock. For a
location recount, use the cycle-count reference
and its documented lifecycle on your deployment.
Neither mechanism is a shortcut for replaying an uncertain receipt. First reconcile whether
the original receiving event already changed its record. Applying another delta can compound
the discrepancy rather than repair it.
Evidence to hand to the next step
Report the shipment or receipt ID, line IDs, quantities counted, observed state, inventory
source and quantities, and any outstanding put-away or discrepancy work. Keep “received” and
“available to sell” as separately verified facts in an operator or agent’s completion report.
