Посібник з інтеграції Monitor ERP для календарного планування виробництва у SkyPlanner APS

Документований інтерфейс інтеграції Monitor G5 — Monitor ERP API v1. Він поєднує CQRS і REST та передає JSON через HTTPS. (Monitor ERP API)

• Запити зчитують дані за допомогою GET. Вони підтримують параметри у стилі OData: $filter, $select, $expand, $orderby, $top і $skip.
• Команди записують дані за допомогою POST, наприклад Manufacturing/ManufacturingOrderOperations/Update.
• Batch виконує кілька команд в одній транзакції за принципом «усе або нічого» через POST /api/v1/Batch. Додайте /Simulate або /Validate, щоб перевірити пакет і відкотити зміни. Так можна безпечно записати весь розклад. (Batch)

Базова URL-адреса — https://{host}:8001/{languageCode}/{companyNumber}/api/v1/. Номер компанії поєднує номер бази даних та ідентифікатор компанії, наприклад 004.1.

Щодо ліцензування Monitor зазначає: “It is free to query and extract information from the API for all our customers. However, in order to use commands and write data to the ERP system, you need to purchase Monitor ERP API.” (Усі наші клієнти можуть безкоштовно запитувати й отримувати інформацію через API. Однак для використання команд і запису даних до ERP-системи потрібно придбати Monitor ERP API.) Передбачте ліцензію на запис даних у проєкті від самого початку. (api.monitor.se)

У довіднику Monitor ERP API не описано вебхуків або підписок на події. Зміни виявляють шляхом опитування:

• Common/EntityChangeLogs (починаючи з версії 2.33) повертає ChangeType (Update, Create, Delete), EntityTypeId, EntityId і ModifiedTimestamp. Опитуйте цей ресурс кожні кілька хвилин і отримуйте лише змінені записи. (EntityChangeLog)
• У запитах виробничих замовлень відбирайте лише відкриті замовлення й отримуйте результати посторінково за допомогою $top і $skip.

SkyPlanner надсилає вебхуки, коли змінюється стан або розклад, тому зворотний запис даних запускається подіями.

1. Початкове завантаження основних даних. Зчитайте робочі центри, рядки технологічних операцій, рядки альтернативних технологічних операцій, рядки матеріалів, номенклатуру та графіки. Уважно зіставте кожен робочий центр Monitor із робочим центром SkyPlanner. Робочий центр типу Pool стає групою робочих центрів, а центри, що входять до нього, — робочими центрами, між якими обирає рушій планування.

2. Синхронізація замовлень. Зчитайте відкриті виробничі замовлення з їхніми вузлами, технологічними операціями та матеріалами, а також складські запаси й відкриті замовлення на закупівлю. SkyPlanner вважає замовлений матеріал доступним на дату постачання, зазначену в замовленні на закупівлю, та оновлює запаси, коли це замовлення отримує статус Delivered. Після першого завантаження зміни визначаються за Common/EntityChangeLogs.

3. Зворотний запис розкладу. Для кожної технологічної операції, яку рушій додав до розкладу або переніс, SkyPlanner надсилає ManufacturingOrderOperations/Update із PlannedStartDate і PlannedFinishDate. Якщо рушій переніс технологічну операцію на інший верстат у пулі, спочатку виконується SetWorkCenter. Команди для одного замовлення об’єднуються в один Batch, тому Monitor приймає або всі команди, або жодної. Під час тестування перевіряйте пакет через /Validate.

У версіях Monitor до 24.5 заплановані дати не можна записувати через Update. Натомість використовуйте ManufacturingOrders/ReplanOperation (починаючи з 2.40) із StartDate і FinishDate та встановіть RestrictToOrderBounds відповідно до ваших правил.

4. Підтвердження виконання в цеху. Залиште один канал реєстрації:

• Каналом залишається Monitor. Оператори, як і раніше, реєструють виконання через Recording terminal або інтеграцію з обладнанням. SkyPlanner зчитує ManufacturingOrderOperationReportings як дані про хід виконання та переплановує розклад.
• Каналом стає SkyPlanner. Оператори реєструють роботу через Mobile Confirmations або Production Timer, а SkyPlanner надсилає ReportManufacturingOrderOperation до Monitor.

Реєстрація в обох системах призводить до дублювання даних про час і кількість.

5. Правила відповідальності за дані та розв’язання конфліктів. Зафіксуйте їх до запуску в експлуатацію:

Основна причина конфліктів — планувальники й далі змінюють пріоритетний план. Rescheduling according to New finish і перетягування рядків у Priority planning перезаписують дати, які записав SkyPlanner. Коли за послідовність відповідає SkyPlanner, Priority planning використовують лише для перегляду. З Autopilot SkyPlanner автоматично переплановує графік у разі змін у виробництві.

• Коефіцієнт доступності. Monitor розраховує чисту потужність із валової за допомогою коефіцієнта доступності. Для нового робочого центру він за замовчуванням становить 80 %. Врахуйте його лише один раз: або як ефективність у SkyPlanner, або як скорочення тривалості змін, але ніколи обома способами одночасно.
• Точність часу. Для робочих центрів у режимі Day planning потужність задається базовою тривалістю роботи на день, без часу початку й завершення змін. Налаштуйте в SkyPlanner фактичні зміни на основі виробничих графіків, щоб завдання потрапляли в робочий час.
• Час очікування та перекриття. Рядки технологічних операцій містять час очікування та перекриття у %. Під час визначення обсягу узгодьте, як кожен із цих параметрів передаватиметься до SkyPlanner, інакше після запуску зміняться строки виконання.
• Пули. Робочі центри пулу плануються в Pool planning, а не в Priority planning. Зчитуйте робочі центри, що входять до пулу, а не лише рядок самого пулу.
• Вимоги до версії. Для запису планових дат через Update потрібна версія 24.5. Для полів потужності робочих центрів в API потрібна версія 24.3, а для OIDC — 25.8. Перевірте збірку до визначення обсягу.
• Мережа та сертифікат. Локально встановлений Monitor надає доступ до API через порт 8001 із самопідписаним сертифікатом. SkyPlanner працює у хмарі, тож передбачте правило брандмауера або ретранслятор і явно додайте сертифікат до довірених.
• Ліцензії. Кожному сторонньому застосунку, який записує дані, потрібні власні користувачі з ліцензією API. До кожної системи входить один користувач API з доступом лише для читання.