У 2025 році 78% користувачів інтернету в ЄС купували онлайн (Eurostat, E-commerce statistics for individuals, 2025). Для рітейлера з мережею магазинів і власним сайтом це означає, що два канали продають товар з однієї полиці. Якщо кожен канал рахує залишки по-своєму, останню одиницю продають двічі — і один із покупців дізнається про це з листа про скасування замовлення. Розв’язує проблему єдина цифра залишку: за нею всі канали показують наявність, резервують товар і називають строки доставки. Нижче — як Microsoft Dynamics 365 забезпечує залишки товарів у реальному часі та які рішення під час впровадження визначають, чи буде ця цифра точною.
Чому магазин і сайт показують різні залишки
Запитайте директора магазину й керівника e-commerce, скільки одиниць хіта продажів залишилося, — відповіді рідко збігаються. Microsoft прямо пояснює причину. У стандартному Microsoft Dynamics 365 Commerce наявність, яку протягом робочого дня бачать POS, e-commerce API та головний офіс, — це розрахункова оцінка, а не гарантований показник у реальному часі. Канал бере останній відомий головному офісу залишок і додає до нього ще не синхронізовані продажі в магазинах, замовлення клієнтів, повернення та відвантаження.
Схема працює, доки два канали не продадуть ту саму останню одиницю протягом години. Тоді бізнес платить двічі: скасованими замовленнями і товаром, який притримують від сайту «про всяк випадок». В обох проблем одне джерело — омніканальні залишки, які майже правильні.
Inventory Visibility: спільний реєстр залишків для всіх каналів
Надбудову Inventory Visibility для Microsoft Dynamics 365 Supply Chain Management створено саме для цього. Вона працює як окремий мікросервіс на Microsoft Dataverse і фіксує зміни залишків у реальному часі з усіх джерел даних і каналів — зокрема із систем поза Dynamics 365. Компанії з ліцензією Supply Chain Management отримують її без додаткової оплати — у межах лімітів сховища та API Microsoft Power Platform.
Якщо рітейлер має ліцензії на обидва продукти, Inventory Visibility можна призначити постачальником даних про запаси для Dynamics 365 Commerce. Тоді застосунок Store Commerce, інтернет-магазин і headless commerce API звертаються до одного актуального показника. Товар резервується, коли клієнт створює, змінює чи скасовує замовлення, а під час комплектації та повернень залишок коригується. Коли ці замовлення згодом синхронізуються із Supply Chain Management, автоматичне взаємозалікування (offset) прибирає вже проведені кількості — тож жодна одиниця не враховується двічі.
Саме так на практиці виглядають залишки товарів у реальному часі для ритейлу на Dynamics 365: один реєстр, з якого всі канали читають дані й у який усі їх записують.
М’яке резервування: кому дістанеться остання одиниця
М’яке резервування (soft reservation) вирішує, хто отримає останній товар. Microsoft розробила цей механізм для компаній, де замовлення приймають дві або більше систем і подвійний продаж неприпустимий. У прикладі Microsoft Supply Chain Management ще показує товар, який Inventory Visibility уже пообіцяла веб-замовленням, що поки не синхронізувалися. Коли кол-центр намагається зарезервувати цей товар, запит відхиляється — Inventory Visibility звіряє його з фактичним залишком.
Крім того, у Supply Chain Management кожен рядок замовлення на продаж має рівень блокування — Block, Warning або Ignore. Він визначає, що відбувається, якщо м’якого резерву немає. Block робить правило жорстким, Warning дозволяє користувачеві його обійти. Цей вибір — за комерційною командою: саме вона вирішує, що для бізнесу прийнятніше — втратити продаж чи ризикнути вибаченням перед клієнтом.

Розподіл запасів і available to promise: рішення до появи попиту
Резервування працює із замовленнями, які вже існують. Розподіл запасів (allocation) захищає дефіцитний товар ще до першого замовлення. Планувальники можуть закріпити кількості за інтернет-каналом, окремими регіонами чи ключовими групами клієнтів, а Inventory Visibility захищає цей запас від інших розподілів, резервувань і попиту з боку продажів. Microsoft рекомендує спершу розподілити запас, а потім робити м’яке резервування в межах розподілу — так споживання кожного каналу відстежується щодо його квоти майже в реальному часі. Групи розподілу мають до восьми рівнів вкладеності: наприклад, канал, далі регіон, далі група клієнтів.
Available to promise (ATP) — прогноз доступного залишку на найближчі дні — продовжує ту саму логіку. Команди можуть налаштувати формули ATP, що охоплюють усі канали та джерела даних, незалежно від того, чи належать вони до Dynamics 365. Для самовивозу з магазину (click-and-collect) і доставки додому це різниця між обіцяною датою і датою навмання.
Чотири рішення, які варто ухвалити до запуску
Залишки в реальному часі — результат налаштувань, а не просто ввімкнена надбудова. Результат визначають чотири рішення:
- Визначте, що означає «в наявності» для кожного каналу. Омніканальний облік запасів починається з домовленості, які джерела даних і показники формують цифру, за якою продає сайт, — і ту, яку бачить магазин.
- Зафіксуйте рівні вимірів (dimensions) на старті. Розподіл для одного товару завжди має використовувати той самий рівень вимірів, інакше дані розподілу стають неузгодженими.
- Залиште Supply Chain Management основною обліковою системою. Inventory Visibility не може змінювати дані Supply Chain Management: потік даних із неї односторонній, і інтеграції потрібно проєктувати з урахуванням цього.
- Перевірте налаштування м’якого резервування в production, а не лише в sandbox. Microsoft попереджає, що типова конфігурація змінювалася від версії до версії, тож два середовища можуть стартувати з різних налаштувань.
OntargIT впроваджує Dynamics 365 для рітейлерів, які продають і в магазинах, і онлайн. Ритейл-практика компанії охоплює омніканальну торгівлю, інтеграцію POS у реальному часі та відстеження запасів у реальному часі. Серед клієнтів — COMFY (82 магазини у 40 містах України), Eldorado (150+ магазинів і два інтернет-магазини) та Chanel, де OntargIT реалізувала інтеграцію з POS і WMS, а також локалізацію для України.
Висновок
Залишки в реальному часі — це рішення, яке ухвалюють під час впровадження, а не опція, яку вмикають після запуску. Надбудова дає спільний реєстр, а Ваша команда визначає, що означає «в наявності» для кожного каналу, кому дістається остання одиниця і який запас для кого захищений. Перед наступним піковим сезоном перевірте, як Ваша поточна конфігурація відповідає на чотири питання вище.

















