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

MRPeasy постачається як один хмарний продукт без версій для локального розгортання, тому всі клієнти використовують однаковий API. Існують дві версії:

1. REST API v1 (OpenAPI 1.0, сервер https://api.mrpeasy.com/rest/v1) — це API для промислової експлуатації. Він охоплює /items, /boms, /routings, /manufacturing-orders, /work-centers, /work-center-types, /customer-orders, /purchase-orders, /stock/inventory, /lots, /units і виробничі звіти, зокрема /report/production/operations.
2. REST API v2 (OpenAPI 2.0.0, сервер https://api.mrpeasy.com/rest/v2) перебуває на ранньому етапі розробки. У ньому додано /workstation-groups із work_hours та holidays, /workstations із productivity та idle, а також /inventory, /stock-movement і PATCH. Виробничі замовлення залишаються у v1.

Зверніть увагу на назви. Workstation group в інтерфейсі MRPeasy відповідає work-center-types у v1 (type_id). Workstation відповідає work-centers (center_id). Технологічні операції маршруту посилаються через type_id на групу, а не на верстат.

API доступний у тарифному плані MRPeasy Unlimited для платних облікових записів. MRPeasy також зазначає: “Our Support Department cannot help you using the API.” (Наш відділ підтримки не може допомогти вам із використанням API.) Тому потрібен відповідальний за інтеграцію: SkyPlanner, ваш консультант із MRPeasy або ваш розробник. Саме цю роботу команда SkyPlanner бере на себе під час впровадження.

На сторінці тарифів MRPeasy зазначено “API, webhooks (for paid accounts)” (API, вебхуки для платних облікових записів), проте специфікації v1 і v2 не описують жодних подій вебхуків для виробничих замовлень. Тому інтеграція опитує MRPeasy, отримуючи зміни:

• Виробничі замовлення відбираються за статусами Not scheduled (15), Scheduled (20), In progress (30) та Paused (35).
• Замовлення на закупівлю та складські залишки зчитуються за розкладом або перед кожним розрахунком графіка.
• Основні дані зчитуються в разі змін або щоночі.

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

1. Початкове завантаження основних даних. Отримайте номенклатуру, одиниці виміру, BOM і технологічні маршрути з v1, а групи робочих центрів і робочі центри — з v1 або v2. Візьміть календарі з v2 /workstation-groups (work_hours, holidays) або задайте зміни безпосередньо в SkyPlanner. Зіставте кожну групу Active processing із групою робочих центрів у SkyPlanner, включивши до неї відповідні робочі центри.

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

3. Зворотний запис графіка. PUT /manufacturing-orders/{id} підтримує code, quantity, due_date та assigned_id, а також користувацькі поля у форматі custom_<id>. SkyPlanner записує планове завершення в due_date, якщо це погоджено, а плановий початок, планове завершення та стан виконання — у користувацькі поля MRPeasy. Тоді відділи продажів і закупівель бачать у MRPeasy реальний графік. Детальна послідовність технологічних операцій і призначений для кожної з них робочий центр зберігаються в SkyPlanner, який слугує диспетчерським інтерфейсом для цеху.

4. Замовлення, створені поза MRPeasy. Якщо замовлення створюються через API, POST /manufacturing-orders приймає no_scheduling та no_bookings. Використовуйте їх, щоб MRPeasy не резервував робочі центри, роботу яких уже планує SkyPlanner.

5. Підтвердження виконання в цеху. Оператори реєструють роботу за допомогою SkyPlanner Mobile Confirmations, Production Timer або Quick Log Mode, а графік оновлюється на основі записів часу. Виберіть один канал реєстрації виконання. Паралельне використання Internet-kiosk від MRPeasy та SkyPlanner для тих самих технологічних операцій створює дві версії фактичних даних.

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

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

• Поля часу відрізняються залежно від інтерфейсу. Полям Setup time, Cycle time та Capacity в інтерфейсі користувача відповідають fixed_time, variable_time та variable_quantity в API. Значення Capacity понад 1 означає обробку партіями, як у печі. Зіставляйте це з виробничим завданням на партію, а не з довшим циклом.
• Групи Passive processing. Групи сушіння й охолодження працюють 24/7 без обмежень потужності. Зіставляйте їх із часом очікування, а не з робочими центрами з обмеженою потужністю.
• У v1 немає календарів. work-centers повертає лише center_id, type_id, code та title. Використовуйте v2 або ведіть зміни в SkyPlanner.
• Час простою. У даних про час простою робочого центру зберігаються періоди технічного обслуговування та простоїв. Синхронізуйте їх, інакше SkyPlanner запланує роботу на верстаті, який не працює.
• Технологічні маршрути посилаються на групи. MRPeasy обирає верстат із найкращою доступністю. У SkyPlanner робочі центри групи стають повноцінними альтернативами, між якими обирає рушій планування.