@stateset/embedded 1.35.1 in a fresh local database. No hosted API key,
carrier connection, or warehouse service is required.
In this version,
inboundShipments.receiveLine updates the inbound shipment’s received
quantity and state. The program verifies that it does not increase inventory on hand.
Posting sellable stock and assigning a warehouse location are separate integration work.Prerequisites
Use Node.js 20.20.0+ and npm 10+:Run the complete example
Save this asreceiving-demo.mjs:
Understand the identities and quantities
Use the returned shipment item ID, not the product ID, as the second argument to
receiveLine(shipmentId, itemId, quantity). Quantity inputs and received totals are decimal
strings. The received quantity is cumulative, but each call supplies an additional quantity:
four followed by six yields ten. Sending ten after the initial four would exceed the expectation.
markArrived records arrival; it does not count the contents. The partial and final receiving
calls record the quantities counted for the line. This example has one line; inspect all lines
when adapting it to a multi-item shipment.
Handle retries and discrepancies
This method’s published Node signature has no idempotency-key parameter. Do not treat an identicalreceiveLine call as a read or an overwrite: it adds another quantity when accepted.
An excess-quantity guard is not duplicate detection; a repeated small receipt can still fit
within the expected total.
Keep a durable identity for each physical receiving event in your integration, together with
its shipment/line IDs, counted quantity, and outcome. If the call’s result is lost, reconcile
the original event and stored received quantity before sending another delta. Coordinate writers
so two workers do not independently apply the same scan or delivery event.
A mismatch between expected and counted goods needs an explicit operational decision. Do not
change the count to make the shipment look complete. Report damaged, missing, or excess units
to the process that owns disposition and supplier follow-up.
Keep receiving and stock posting separate
The final shipment isreceived, while inventory.getStock still reports zero. The example
has neither posted stock to a bin nor updated a purchase order, supplier bill, or external WMS.
Do not tell another agent that these units are sellable based only on the shipment status.
Choose the receiving and inventory process your system actually uses, map its record IDs, and
verify both outcomes. Simply following every receipt with inventory.adjust would introduce
a second write whose retries and failure recovery you must design; it is not an atomic
receiving transaction supplied by this example.
The receiving and put-away guide distinguishes these
records and points to the relevant contracts. The inventory quickstart
shows stock adjustments and reservations separately.
Give an agent a receiving task
For a read-only check, supply the actual shipment ID and ask the agent to report its status, each line’s expected/received quantities, and separately observed inventory. Have it identify the tool results behind its answer. Do not infer stock availability from the receipt total. For a write task, also supply the exact line ID, the additional quantity physically counted, the receiving-event identity, and the configured authorization for that operation. Discover the installed server’s tool schema rather than translating these Node method names into guessed MCP tool names. Use the agent operating procedure.Troubleshooting
Next steps
- Supplier and purchasing: create a PO and verify its approval state.
- Receiving and put-away: identify the next record and verification boundary.
- Inventory: check on-hand, allocated, and available quantities.
- Connect your operation: map warehouse and external-system ownership.
- Integration tests: assert unchanged state after rejected writes.