Назад до новин

Автоматичне схвалення бронювання часового вікна для кожного замовлення в Business Central

Pavel NOVOTNÝ
Блог
Автоматичне схвалення бронювання часового вікна для кожного замовлення в Business Central

Резервування часового вікна створюється в Time Slot Control. Однак порядок, за яким має бути прийнято його затвердження, лежить у ERP. Як з'єднати обидва світи без ручного переписування і без постійних запитів до API?

Одним із варіантів є автоматизований хмарний потік у Microsoft Power Automate. Time Slot Control надсилає вебхук, Power Automate заповнює необхідний контекст через OData, перевіряє наказ у Microsoft Dynamics 365 Business Central або Dynamics NAV і, залежно від результату, затверджує бронювання або повідомляє диспетчера в Microsoft Teams.

Практичний сценарій: Затвердити бронювання наказом у ERP

Уявімо, що перевізник створює бронювання для розвантаження. Операція хоче автоматично затвердити його лише тоді, коли в ERP є відкрите замовлення для відповідної компанії та запланована дата доставки.

Цю вимогу не можна вирішити простим правилом у системі бронювання. Рішення залежить від поточних даних у Business Central або NAV. Отже, інтеграція поєднує три інтерфейси:

  • вихідний вебхук з Time Slot Control як миттєвий тригер,
  • OData для отримання бронювання та деталей компанії,
  • REST API для запису результату назад у Time Slot Control.

Power Automate workflow connecting Time Slot Control with Microsoft Dynamics 365 Business Central or Dynamics NAV

Як працює робочий процес

1. TSC надсилає подію без очікування голосування

Flow починається з HTTP-тригера в Power Automate. Його адреса використовується підпискою в Time Slot Control для події reservation.pending. Таким чином, інтеграція починається, коли потрібно прийняти рішення, і не потрібно щохвилини переглядати API в пошуках змін.

Вебхук використовує стабільну обгортку зі схемою, ідентифікатором події, типом події, орендарем, часом походження та короткими даними бронювання:

{
  "schemaVersion": "1.0",
  "eventId": "7d897a13-9ac6-4d3f-9cdb-4ad2dd943be1",
  "event": "reservation.pending",
  "tenantId": "2d90ece5-b724-49b0-a19c-08e5b0a63cda",
  "occurredAt": "2026-09-18T07:58:42Z",
  "data": {
    "id": "37efcb13-f1cb-4a61-baea-adfb4337036f",
    "approvalStatus": "pending",
    "deliveryDateUtc": "2026-09-18T08:00:00Z"
  }
}

Корисне навантаження навмисно є економічно вигідним. Воно не містить повного бізнес-контексту і не стає зайвим, копіюючи десятки полів. Power Automate отримує деталі, необхідні для прийняття рішення, лише на наступному кроці.

2. Flow завершує контекст бронювання через OData

Перша HTTP-дія отримує деталі резервування з TSC, такі як її номер, початок часового вікна, джерело та користувач, який її створив. Друга дія визначає компанію цього користувача.

Це важлива деталь: компанія-перевізник, зазначений у бронюванні, не обов'язково має бути такою ж, як і компанія, чий користувач зробив бронювання. Отже, відображення з номером клієнта в ERP має відповідати конкретному бізнес-процесу.

3. Business Central або NAV підтверджують замовлення

У Business Central Power Automate може застосовувати стандартну дію Find records (V3) до замовлень на продаж. Типовий фільтр об'єднує номер клієнта, необхідну дату доставки та статус замовлення. Ви можете додати локацію, склад, місце посадки або власний ідентифікатор інтеграції за потреби.

У Dynamics NAV логіка прийняття рішень залишається незмінною. Flow працює з даними, опублікованими через сервіс OData інсталяції. Конкретна сутність, назви полів і метод входу налаштовуються відповідно до версії NAV та налаштувань клієнта.

Отже, Power Automate — це не інша база даних. Він лише координує кроки та приймає рішення щодо поточних даних у TSC та ERP.

4. Рішення про засновення затверджує резервування

Якщо відкритий наказ збігається з бронюванням, потік викликає дію REST API для затвердження:

POST /v3/{tenant}/Reservations/{id}/Approved

Контроль часових слотів продовжується стандартним процесом: зміна статусу видима користувачам, і оператор може отримувати регулярне сповіщення відповідно до конфігурації клієнта. Інтеграція не обходить існуючий робочий процес, вона лише автоматизує рішення, для якого має достатньо даних.

5. Відсутність порядку залишається завданням для людини

Якщо відповідного замовлення в ERP немає, резервація залишається у стані очікування затвердження. Power Automate надсилає адаптивну картку в Microsoft Teams диспетчеру з номером бронювання, компанією, зустріччю та посиланням TSC.

Результатом не є сліпе відхилення. Диспетчер отримує інформацію у потрібний момент і може перевірити виняток, виправити відображення або прийняти рішення вручну. Автоматизація вирішує стандартні випадки, а над нестандартними зберігають контроль.

Чому вебхук замість регулярних опитувань

Під час опитувань інтеграція повинна неодноразово запитувати дані навіть тоді, коли нічого не змінилося. Зі зростанням кількості орендарів, резервацій і підключених систем це означає зайвий трафік і складніший моніторинг часового вікна.

Вебхук змінює напрямок комунікації. TSC надсилає подію лише тоді, коли вона фактично відбувається. Power Automate тоді отримує лише ті дані, необхідні для конкретного рішення. Результат — швидша відповідь, менше зайвих запитів і чіткіша інтеграція.

Автоматизоване затвердження бронювання між TSC та ERP

Microsoft пропонує власний роз'єм Power Automate для Dynamics 365 Business Central з діями для пошуку та роботи з записами. Dynamics NAV можна підключити за допомогою відповідного роз'єму та опублікованого сервісу OData, залежно від версії. Різниця полягає в технічному з'єднанні, а не в процесі: подія створюється в TSC, ERP надає бізнес-контекст, а результат записується назад у TSC.

Детальніше дивіться у огляді інтеграцій Time Slot Control, документації роз'ємів Business Central Dynamics 365 та роз'єму Dynamics NAV.

Де ще можуть допомогти вебхуки

Автоматичне схвалення бронювання — лише один із прикладів. Такий самий шаблон інтеграції може використовуватися й на інших етапах процесу для з'єднання TSC з Business Central, Dynamics NAV, WMS, транспортними системами або командною комунікацією.

Автоматична реєстрація прибуття транспортного засобу

Подія reservation.markedasarrival може одразу записати фактичний час у ERP, коли автомобіль прибуває, оновити статус відповідного замовлення та повідомити склад або диспетчер у Microsoft Teams.

Точний час початку та завершення завантаження

Вебхуки reservation.processingstarted та reservation.processingcompleted передають фактичний процес реєстрації до Business Central або WMS. Таким чином компанія отримує більш точні дані для оцінки очікування, роботи на рампі та дотримання запланованого часу.

Негайна реакція на відсутність авіаносців

Подія reservation.carrier.notarrived може створити виняток у ERP, повідомити диспетчера і розпочати процес на альтернативну дату. Проблему починають вирішувати негайно, а не лише під час подальшої ручної перевірки.

Синхронізація змін бронювання без ручного переписування

Під час перенесення зустрічі або зміни транспортного засобу, водія чи відділення події reservation.moved, reservation.vehicle.platechanged, та reservation.driver.changed reservation.branchoffice.changed. Отже, системи нижчого рівня працюють з тими ж даними, що й TSC.

Автоматичне закриття транспорту та подальші кроки

Вебхуки reservation.markedasdeparted можуть reservation.delivered завершити транспортування або замовлення в ERP-системі після відправлення або доставки, передати документи для документування та розпочати подальші кроки до виставлення рахунків.

Чи хочете ви перевірити подібний процес на власних даних?

Той самий шаблон може використовуватися не лише для затвердження бронювання, а й для перегляду замовлень, призначення напряму, синхронізації статусу або сповіщень про відсутні дані. Спочатку сценарій перевіряється у тестуванні TSC та ERP-тесту, і лише після цього виробничі системи підключаються.

Зв'яжіться з нами. Разом ми розробимо інтеграційний робочий процес відповідно до ваших процесів, дозволів та конкретної версії Business Central або Dynamics NAV.

Назад до новин