Availability snapshot
A change-tracked table of current item availability that the extension keeps up to date so integration tools can subscribe to stock changes by webhook. It is off by default. Turn it on only if your integration consumes availability.
Business Central does not expose "current availability" as a single, webhook-able number. It is derived on demand from ledger and reservation entries. To let an external tool subscribe to stock changes, the extension maintains a materialized snapshot: one row per item (per location, if you track by location) holding on-hand, reserved, safety stock, quantity on purchase order, and a derived available quantity. The itemInventoryAvailabilities endpoint reads it, and it is change-tracked, so writing a row fires a realtime trigger.
How it stays current
- A posting or reservation changes inventory for an item.
- The extension enqueues the affected
(item, location)key into the availability buffer. A transient work queue that nobody edits. It does not recompute inside the posting transaction, so posting stays fast. - A background refresh job drains the buffer and recomputes each affected snapshot row.
- Writing the row trips change tracking → the availability webhook fires to subscribers.
On a fresh install the snapshot is seeded from current inventory; an upgrade backfills it.
Turning it on and tuning it
Turn it on on the Features tab of eOne Integration Setup. It is off by default so an integration that does not use availability pays no per-posting cost. Once it is on, the Item Availability section appears on the Events & Webhooks tab, where you tune:
- Granularity. Per location (one row per item and location) or company-wide (one aggregated row per item). Choose company-wide if you do not track inventory by location.
- Basis. The formula used to derive the published available quantity. The raw components are always published too, so a subscriber can apply its own formula.
- Include blocked items / in-transit locations / blank location. Scope filters; blocked items are suppressed by default, and the location filters apply only under per-location granularity.
Because enabling availability or changing any of these settings re-shapes every snapshot row, the setup card asks you to confirm and choose how to apply the change:
- Run now recomputes the affected rows immediately, in the same session. Use it for a small catalog where you want the snapshot (and its webhooks) current at once.
- Stage for the background job (recommended for many items) queues the work into the availability buffer and lets the refresh job drain it over its next cycles, so the client is not tied up by a long inline rebuild. This is the default, and the one to pick for a large catalog.
Turning availability off applies immediately and needs no choice.
Operating it
- Availability Backlog (setup card action) shows the recompute queue. A growing or aging backlog means the refresh job is not keeping up.
- Rebuild Availability Snapshot re-evaluates every row against the current settings now, rows that no longer qualify are removed and the rest recomputed.
Next: Troubleshooting. What to check when notifications are not firing.