Inventory

Inventory owns physical stock: SKU identities, locations, quantities, reservations, movements, and receipts. Commerce owns products, prices, checkout, and orders. A storefront must use those authorities instead of maintaining another stock counter.

Inventory is planned after v1. This page describes its development contracts, not an available installation or production stock-management procedure. It is not required for the first unmanaged product or TEST order.

When Inventory is needed

The development contract distinguishes unmanaged and managed products. An unmanaged product uses Commerce's manual availability and sends no stock commands. A managed product uses one configured inventory provider. DinkusKit Inventory is the intended first-party provider, but that contract does not establish a released owner setup or an independently installable provider SDK.

The current Template Store shipping profile keeps Inventory off. Its managed-stock demonstration is a separate development profile. This is why Inventory must not be listed as a universal prerequisite for the first test order. Older descriptions of Commerce and Inventory launching together describe product direction; they do not prove a mandatory dependency or a released managed-stock configuration.

Existing managed products must retain their identity and configuration. If their provider is missing, incompatible, or unavailable, the contract refuses stock-dependent operations. It does not convert the product to unmanaged or substitute a local quantity.

Read stock in context

An inventory pool groups stock under one authoritative ledger. Each physical location has its own quantities, and each storefront connection has an explicit fulfillment location. Matching product names or SKUs do not establish that mapping.

For example, ten on hand with three reserved and two committed to a transfer leaves five available. Expected and in-transit stock do not increase current availability.

Changes have receipts

The command contract requires a stock change and its immutable receipt to commit together. Opening stock begins with a physical count and reviewed opening balances. Later corrections create new movements; they do not rewrite old receipts.

A successful preview changes no stock. A confirmation must return a committed result before the caller treats the change as complete. After a timeout, the outcome is unknown: resolve or retry the original command identity with the same contents. Creating a replacement command could apply the change twice.

The reviewed source includes SKU registration, initial-stock and adjustment previews and confirmations, stock views, and location-move controls in the EmDash plugin. It also contains hosted routes and reservation/transfer kernels. This establishes implementation scope in source, not proof that every operation is available to a particular installed store.

Current release limits

The reviewed Inventory root and EmDash plugin packages remain private at 0.0.0. Current source targets EmDash 1.2.0; the README's older 0.41.0 statement is historical. The documentation tracker explicitly places Inventory after v1.

A supported owner guide still needs an exact released artifact, verified Registry installation, account connection, and a tested Commerce/provider combination. Until those are established, this page supplies no installation command or production migration procedure. Manufacturing, purchasing, and legacy-system synchronization are outside this reference's scope.

Sources

The links below document development behavior. No stock was changed as part of this documentation review. The current release boundary is recorded in the documentation tracker.

• Product and provider contracts.
• Command and receipt contract.
• Root package, plugin package, and plugin manifest.
• EmDash plugin implementation and hosted route implementation.
• Template Store shipping-profile boundary, pinned separately to 75f49ff6ded989726a76676eb27d8ae9b64ab980.
• Inventory remains after v1