Endless aisle and cross-store inventory in Dynamics 365 Commerce

Endless aisle is the promise that a store never loses a sale to a stock-out: if the item is not on the shelf, the associate sells it anyway and it ships from a warehouse or another store. It is a retail strategy rather than a feature, but it maps onto a specific set of Dynamics 365 Commerce capabilities, and the ones it does not map onto are worth knowing before the project is scoped.

The core mechanism: customer orders at the POS

Commerce's POS does not only ring up cash-and-carry sales. It creates customer orders — sales orders in headquarters that originate in a store — with a delivery mode of ship-to-customer, pick up at this store later, or pick up at another store. The associate adds products, chooses delivery, takes a deposit, and the order flows to headquarters for fulfilment exactly as an e-commerce order would.

That single capability is most of endless aisle. The rest is configuration and operations:

• Deposit policy. Headquarters sets a default deposit percentage per store and whether associates can override it. Full payment up front simplifies accounting but hurts conversion; zero deposit invites no-shows on pickups. Most retailers land on a percentage for pickup orders and full payment for ship-to-home.
• Which products are orderable. Assortment governs what a store can sell, including items it never stocks. An "extended range" assortment assigned to all stores is the usual pattern, separate from the physical range each store carries.
• Product content on the register. Selling something the customer cannot touch needs images, attributes, and rich descriptions on the POS. These come from the product master and media in headquarters; if the merchandising team has not loaded them, the associate is selling from a product number.

Cross-store inventory lookup

The associate needs to answer "do we have it anywhere?" in seconds. The Store Commerce app's inventory lookup queries availability across stores and warehouses through the Commerce Scale Unit, and the accuracy question is the same one that dogs click-and-collect: store on-hand is only as good as statement posting and counting.

For retailers on Supply Chain Management, the Inventory Visibility add-in improves this materially — it maintains a near-real-time on-hand picture across channels and legal entities and exposes it to the POS and storefront. It is a separately configured add-in, not something that switches on by default, and it has its own data-model decisions (which dimensions to track, which soft reservations to honour). Plan for it as a workstream.

Without it, the lookup still works; it just reflects headquarters as of the last sync and can lie at peak.

Fulfilment from somewhere else

Once the customer order exists, fulfilment is a headquarters problem. Ship-from-warehouse orders go through normal sales-order release and warehouse picking. Pickup-at-another-store or ship-from-another-store orders can be routed by distributed order management if it is configured, or simply appear in that store's order-fulfilment queue in the Store Commerce app.

The organisational decisions here outweigh the technical ones:

• Which store gets the sale credit — the selling store or the fulfilling store. Commerce records both the originating channel and the fulfilment location, so reporting can go either way, but store managers will argue about it. Decide once, publish it, and build the Power BI measure accordingly.
• Who bears the shipping cost on a ship-from-store order. Commerce can charge the customer through delivery charges; absorbing it is a merchandising decision that shows up in margin reports.
• Stock transfer versus sale. Do not model "sell it from the other store" as a transfer order followed by a local sale. It creates two documents, doubles the picking work, and breaks the customer's order history. Use the customer order.

Kiosks and self-service

This is where the product stops. Commerce has no first-party kiosk application. The options are a locked-down Store Commerce register in a self-service visual profile (workable for simple flows, awkward for payment), the e-commerce storefront in kiosk mode on a tablet (common and cheap, but it is an online order rather than a store transaction), or a partner kiosk product built on the Commerce SDK. The storefront-on-a-tablet route is usually the right first move because it reuses everything already built for online.

Payments and returns

Deposits and balance payments run through the same payment connector as the rest of the POS. The tricky case is a customer order created in one store, paid in part, and collected in another: the balance payment happens at collection, on the collecting store's terminal, against the original order. Commerce supports it; make sure the acquirer's connector does before promising it.

Returns of endless-aisle orders follow the standard cross-channel return path — any store can return against the headquarters order. That is worth stating in staff training, because associates tend to assume an order they did not create cannot be refunded on their till.

Business Central retailers

Endless aisle on Business Central depends entirely on the POS ISV. Most of the established BC retail add-ons support customer orders from the till with a deposit and ship-from-warehouse fulfilment; cross-store lookup and fulfilment vary widely. Ask the vendor to demonstrate the specific flow — a customer order at store A, collected at store B, with the balance paid at B — rather than accepting "yes, we do endless aisle".

Sequencing

Retailers that succeed with endless aisle usually do it in this order: fix store stock accuracy, load product content, switch on customer orders with a deposit policy, add cross-store lookup, then add DOM and kiosks if the volumes justify them. Doing it in the opposite order — kiosks first — produces impressive demos and a queue of orders that cannot be fulfilled.