Item Availability Realtime-enabled

A read-only feed designed for webhook subscriptions, with one row per item + location (or a single row per item when you track stock company-wide). Each row carries on-hand, reserved, safety-stock and quantity-on-purchase-order figures, plus a pre-netted availableQuantity, and enough item detail to identify and route the product without a second call.

Why it exists

This is a maintained snapshot, not a live calculation. The underlying table holds pre-computed quantities and is change-tracked, so instead of polling and recalculating availability yourself, you POST a subscription against this entity set; Business Central notifies you when a row changes, then you GET the row for the new quantities. Reading a row is a single indexed lookup. That is what makes the webhook cheap at scale.

Off by default: enable it in Setup

The snapshot is not maintained until you turn it on. On a fresh install Item Availability is disabled and its refresh Job Queue entry is seeded in an On Hold state, so the extension adds no posting overhead until someone opts in. An admin enables it on the eOne Integration Setup page (search the page name in Business Central); enabling starts the refresh job and rebuilds the snapshot. Upgrades from a version that pre-dates this setting keep availability on, preserving the previous always-on behaviour.

While the feature is off, this feed and the availability query return an error rather than rows. It is the only read-only endpoint in the extension that does so. Nothing maintains the snapshot while it is off, so the rows it holds are the ones it had when it was switched off. An error tells you the feature is off; stale quantities would not.

What you can configure

• Track Inventory By. Either per location (one row per item + location) or company-wide (a single aggregated row per item, with a blank locationCode). Choose company-wide if you do not track stock by location.
• Available Quantity Formula. How availableQuantity is netted: on-hand; on-hand less reserved; on-hand less reserved and safety stock; or projected (also adding inbound purchase orders). The raw components are always published, so you can still net your own way.
• Include blocked items / in-transit locations / blank-location inventory. Off by default; switch on to widen coverage.

How the snapshot stays current: a job queue drives it

Recompute does not happen inline when stock moves. It runs on a recurring Job Queue entry, so notifications are near-real-time but not instantaneous: they land on the job's cycle. The pipeline has three stages:

1. Capture (instant). Posting an inventory movement, changing a reservation, editing an outstanding purchase line, or changing item/SKU safety stock fires an event. The event does almost no work: it writes the affected (item, location) key into a small buffer table. A posting batch that touches the same key a thousand times collapses to one buffer row, so large postings stay fast. (When availability is disabled, even this capture step is skipped.)
2. Drain (every few minutes). The recurring Job Queue entry (seeded on install, activated when you enable availability, and running about every 5 minutes) reads the buffered keys and recomputes each one once from the item's availability FlowFields, then clears it from the buffer. Keys queued by postings during a run are picked up on the next run. A key that fails to recompute is retried on later runs and only dropped after repeated failures, so one bad row never blocks the rest of the backlog.
3. Notify (on real change only). The recompute is idempotent and writes the row only when a stored quantity actually changed. Writing the row trips change tracking, which is what fires the webhook to subscribers. Re-running the job over an unchanged key writes nothing and raises no notification, so you never get spurious webhooks from a posting batch that did not move the figures.

The row identifies its own item

A webhook tells you an item's stock moved. Acting on that usually means knowing which product it is and whether it can ship, which otherwise means a second call to items for every notification. So the row carries a small amount of item detail alongside the quantities:

Two of these change how you should treat the row rather than merely describing it:

• itemTrackingCode. Non-blank means the item needs lot or serial numbers when it ships, so you know at notification time that fulfilment has to supply itemTrackingLines, rather than finding out when posting fails.
• gtin. The identifier most commerce platforms match on when they do not hold the Business Central item number, so it is usually the join key rather than itemNo.

Everything else about the item (pricing, category, weights, unit-of-measure conversions, the planning and posting setup) stays on the items endpoint. This feed answers "how much is there, and what is it", not "everything about it".

These fields are read live from the item, so they are always current. They are deliberately not part of what triggers a notification. Renaming an item does not fire an availability webhook; this stays a quantity feed, and the new value is there next time you read the row. Sync product data changes from the items feed.

Coverage

Once enabled, the snapshot is seeded for every qualifying inventory item at every physical location (so brand-new items surface as out-of-stock rather than as a missing row), plus every item + location that has ledger history. What qualifies follows your settings: blocked items, in-transit locations, and blank-location movements are excluded unless you include them, and in company-wide mode there is a single row per item instead of one per location.

Filter by location with locationIntegrationId (your external key) as well as the Business Central locationCode. See Resolver fields.