Break the admin salable quantity down by source

[jeanmarcos-dev]

The admin shows the quantity a source physically holds and the salable quantity a stock aggregates, but nothing in between. A merchant looking at Sources reporting 10 on hand and Product Salable Quantity reporting 7 has no way to tell where the missing 3 went, or which source is holding it. With source-level reservations that information exists and is exact; it was simply never exposed.

This adds the missing link: for every source of a stock, the quantity on hand, that source's reservation balance and the salable quantity they add up to.

What changes

Product form — the Product Salable Quantity section now renders one table per stock. The stock name becomes the field label and the aggregate it already reported becomes the last row of the same table, aligned under the Salable column, so the sources visibly sum to the total instead of floating beside it.

Product grid — the Salable Quantity column keeps the aggregate it shows today and gains a toggle that expands the same breakdown. The data already travels in the row, so expanding costs no request.

Sources that contribute nothing are still listed and labelled, because a zero with no explanation reads as a defect:

source state	on hand	reservations	salable
normal	5	−2	3
source item out of stock	5	−2	0
source disabled	10	0	0

Including a disabled source is deliberate. A disabled source still holding stock and pending reservations is the case the indexer had to be fixed for; hiding it in the admin would reproduce the same blind spot.

How it resolves

Two services, both batch:

• InventorySales/Model/SourceReservation/GetSourceAvailabilityBySkus — nets the physical source quantity against that source's reservation balance for a list of SKUs and sources, in two queries regardless of input size. It degrades to the physical quantity when source-level reservations are off, and reports the physical quantity alongside the net so a caller can show how the net was reached. It needs a source-item read that keeps out-of-stock rows (the existing GetSourceItemQuantityBySkusAndSources filters them out, which cannot distinguish an empty source from one holding quantity that is not offered for sale), hence the new GetSourceItemDataBySkusAndSources.
• InventorySalesAdminUi/Model/GetSourceSalableQuantityData — groups the rows under the stock each source belongs to, preserving the stock's priority order, and resolves every SKU in a single availability call. The stock-to-sources resolution is memoised per call, so a grid page of 20 products over 2 stocks does 2 resolutions, not 40.

AddSourceSalableQuantityBreakdown holds the part both surfaces share — which entries carry a breakdown, and the batching — so the form and the grid cannot drift apart. GetSalableQuantityDataBySku is untouched and remains the provider of the aggregate.

The grid adds two queries per page, not per row, which is lighter than the per-row pattern the neighbouring Quantity per Source column already uses.

Gates

The breakdown is skipped, and the section renders exactly as before, when:

• single-source mode is on — the breakdown would only repeat the aggregate;
• the stock is not managed — there is no quantity to break down;
• the product type has no source-item management — the same gate the section already applied;
• the row stands in for more stocks than the column will show.

IsSingleSourceModeInterface was an injected but unused dependency in both the form modifier and the grid column; it moves to the collaborator that now actually uses it.

Rendering

The breakdown reuses the native admin__dynamic-rows cell grid — the same component the Sources section above it in the same form is built from — so the two read as siblings rather than as a bespoke table dropped into the page. The nested table in the grid cell deliberately omits the data-grid class so a data grid is never nested inside another one; admin__dynamic-rows was measured to supply identical computed styles.

Verification

	result
Unit	127/127 (24 new)
setup:di:compile on a real 2.4.8	clean
phpcs (Magento2)	0 errors, 0 warnings
phpmd — CI ruleset and the local Magento ruleset	clean
PHPStan level 6	no new findings
gap-H concurrency harness, 10 rounds	PASS on 2.4.9 — 0 oversold, 0 deadlocks

The module is byte-identical to the 2.4.9 release except the Composer constraints. End to end on a disposable 2.4.9 install with source-level reservations on (SKU SLR-1, slr_a 5 / slr_b 10): baseline aggregate 15 broken down 5 + 10; a source-scoped reservation of −2 on slr_a moves the aggregate to 13 and the row to 5 / −2 / 3 while slr_b stays 10 / 0 / 10; disabling slr_b and setting slr_a's source item out of stock label both rows and zero their salable quantity while keeping the quantity on hand visible; turning source-level reservations off drops the Reservations column and degrades the salable quantity to the quantity on hand. In the grid, expanding does not navigate and issues no request.

The concurrency harness is not strictly required — this change is read-only and never touches the reservation write path — but it was run because the new service lives under InventorySales/Model/SourceReservation/.

Notes

• The aggregate comes from the inventory index while the breakdown reads live rows, so the two can legitimately disagree until a reindex. That is the existing behaviour of GetProductSalableQty, not something this introduces.
• With source-level reservations off, the total can sit below the sum of the rows: reservations are then held per stock and cannot be attributed to a source. That is the honest degradation, and it is the gap source-level reservations exist to close.
• Magento_InventorySalesAdminUi gains a Composer dependency on magento/module-inventory-sales and magento/module-inventory-reservations-api; Magento_InventorySales was already in its module.xml sequence.