Інтеграції / ERP / Odoo
Посібник з інтеграції Odoo зі SkyPlanner APS для календарного планування виробництва
Цей посібник пояснює партнерам Odoo, розробникам та ІТ-керівникам, як підключити Odoo Manufacturing до SkyPlanner APS. Бізнес-обґрунтування та можливості кнопки Plan в Odoo описано на сторінці про календарне планування виробництва в Odoo та у статті «Чи є в Odoo планування виробництва?», де йдеться про складання графіка з урахуванням реальних потужностей обладнання та доступності персоналу.
Odoo залишається системою обліку продукції, специфікацій, операцій, замовлень на виготовлення, запасів і собівартості. На основі цих даних SkyPlanner формує графік за допомогою свого рушія Arcturus. Обмін даними з Odoo відбувається в обох напрямках:
- До SkyPlanner надходять замовлення на виготовлення, виробничі замовлення, операції BoM, робочі центри та замовлення на закупівлю.
- У
mrp.workorderзаписуються планові час початку й завершення та робочі центри. - Дані про хід виконання та облікований час повертаються до Odoo як Time Logs.
- Вебхуки SkyPlanner передають зміни графіка відразу після їх внесення.
Під час початкового налаштування команда SkyPlanner реалізує інтеграцію через стандартний зовнішній API Odoo з урахуванням вашої версії, хостингу та доопрацювань, а після запуску забезпечує її підтримку. Цей посібник призначено для партнерів і розробників, які хочуть долучитися до роботи або самостійно створити інтеграцію на основі документованого REST API SkyPlanner (довідник API). Роботу з продукцією, матеріалами та замовленнями на закупівлю описано у відкритій документації SkyPlanner.
Нульовий крок: перевірте тарифний план і хостинг Odoo
Спочатку з’ясуйте, який варіант Odoo використовує замовник. Від цього залежить спосіб інтеграції.
| Варіант розгортання | Зовнішній API | Власні модулі | Практичний спосіб інтеграції |
|---|---|---|---|
| Odoo Online, One App Free або Standard | Ні | Ні | CSV/XLSX або перехід на тарифний план Custom |
| Odoo Online, тарифний план Custom | Так | Ні | Зовнішній API |
| Odoo.sh (тарифний план Custom) | Так | Так | Зовнішній API, за потреби — модуль |
| На власних серверах, Community або Enterprise | Так | Так | Зовнішній API, за потреби — модуль |
У документації API Odoo зазначено, що доступ до зовнішнього API «only available on Custom Odoo pricing plans» (доступний лише на тарифних планах Odoo Custom), а не на One App Free чи Standard. На сторінці тарифів Standard описано як варіант розміщення на Odoo Online «without custom modules» (без власних модулів). З’ясуйте це під час початкового обстеження, а не посеред розробки.
Варіанти інтеграції з Odoo
| Варіант | Версії | Автентифікація | Роль в інтеграції із системою календарного планування |
|---|---|---|---|
Зовнішній JSON-2 API: POST /json/2/<model>/<method> | З’явився у версії 19.0 | Ключ API у Authorization: bearer <key>, необов’язковий заголовок X-Odoo-Database | Основний варіант для нових інтеграцій: search_read для читання, write для зворотного запису дат |
Зовнішні XML-RPC / JSON-RPC: /xmlrpc/2, /jsonrpc, служби common, object | До 19.0 включно; заплановано видалення | common.authenticate з логіном і паролем або ключем API, потім execute_kw | Потрібні для клієнтів із версіями від 16.0 до 18.0 |
| Власні контролери в модулі | Усі | Для кожного маршруту окремо, наприклад auth='bearer' | Об’єднані дані: замовлення на виробництво (MO) разом із його виробничими замовленнями за один виклик |
| Правила автоматизації: «Send Webhook Notification» (надіслати сповіщення через вебхук) | У документації починаючи з 17.0 | Вихідний POST-запит на URL | Надсилання даних під час створення або редагування MO та виробничих замовлень |
| Імпорт записів (CSV, XLSX) та експорт | Усі | Сеанс користувача | Дані для пробного використання та разове завантаження основних даних |
Підготуйтеся до видалення вже зараз. Odoo запланувала видалення XML-RPC і JSON-RPC в Odoo 22 (осінь 2028) та Odoo Online 21.1 (зима 2027). Для 19.0 будуйте інтеграцію на JSON-2, а для старіших баз даних ізолюйте роботу з RPC в одному адаптері, щоб для оновлення вистачило однієї зміни. Видалення не стосується власних контролерів із @route(type='jsonrpc').
Автентифікація
Створіть окремого користувача для інтеграції з правами читання в Manufacturing та Inventory і правами запису виробничих замовлень. Згенеруйте для нього ключ у меню Preferences > Account Security > New API Key. У версії 19.0 ключі діють щонайдовше три місяці, тому проміжне ПЗ має забезпечувати ротацію ключів і сповіщення про помилки автентифікації. Без цього прострочений ключ непомітно зупинить синхронізацію. REST API SkyPlanner використовує JWT, тож проміжне ПЗ зберігає обидва набори облікових даних.
Кожен виклик JSON-2 виконується в окремій SQL-транзакції, тому запис даних через кілька викликів не є атомарним. Записуйте дані окремо для кожного виробничого замовлення та фіксуйте кожен результат у журналі.
Події
Odoo надсилає зміни через правила автоматизації. Правило для mrp.production або mrp.workorder з тригером On create and edit і дією «Send Webhook Notification» (надіслати сповіщення через вебхук) надсилає POST-запит із вибраними полями на вказаний URL. Створіть правило в Studio або в режимі розробника через форму Automation Rules. Доповніть його періодичним опитуванням через search_read за полем write_date, щоб отримувати імпортовані дані та все, що пропустило правило. У зворотному напрямку вебхуки SkyPlanner надсилають зміни графіка та станів одразу після їх виникнення.
Назви полів відрізняються залежно від версії. У 19.0 кожна база даних надає перелік своїх моделей, полів і методів за адресою /doc; у старіших версіях викликайте fields_get. Налаштовуйте відповідність полів за цими даними, а не з пам’яті.
Зіставлення даних: з Odoo до SkyPlanner
| Модель Odoo | Об’єкт SkyPlanner | Напрямок | Періодичність |
|---|---|---|---|
product.product / product.template (default_code, uom_id, qty_available) | Виріб або матеріал | Odoo → SkyPlanner | Початкове завантаження, далі щодня або в разі змін |
mrp.bom (product_tmpl_id, product_qty, produce_delay), mrp.bom.line (product_id, product_qty, operation_id), mrp.bom.byproduct | Виріб із багаторівневою структурою, потреби в матеріалах для кожного етапу | Odoo → SkyPlanner | У разі змін |
mrp.routing.workcenter (вкладка Operations: workcenter_id, sequence, time_mode, time_cycle_manual, blocked_by_operation_ids) | Етапи процесу з послідовністю та тривалістю виконання | Odoo → SkyPlanner | У разі змін |
mrp.workcenter (resource_calendar_id, time_efficiency, time_start, time_stop, alternative_workcenter_ids) | Робочий центр, ефективність, налагодження та завершальні роботи, альтернативні робочі центри | Odoo → SkyPlanner, подальше ведення даних у SkyPlanner | Початкове завантаження |
mrp.workcenter.capacity (capacity) | Кількість одиниць за цикл, час налагодження та завершальних робіт для конкретного виробу | Odoo → SkyPlanner | Початкове завантаження |
resource.calendar, resource.calendar.attendance, resource.calendar.leaves | Зміни та відсутності | Odoo → SkyPlanner | Початкове завантаження, відсутності — у разі змін |
mrp.production (product_id, product_qty, date_deadline, priority, state, workorder_ids) | Замовлення з терміном виконання та пріоритетом | Odoo → SkyPlanner | Вебхук під час підтвердження та опитування |
mrp.workorder (operation_id, workcenter_id, duration_expected, state) | Виробниче завдання на робочому центрі | Odoo → SkyPlanner | Вебхук та опитування |
stock.quant, stock.move (рух компонентів) | Наявні запаси та потреби в матеріалах для планування з урахуванням доступності матеріалів | Odoo → SkyPlanner | За розкладом, наприклад кожні 15–60 хвилин |
purchase.order (partner_id, state), purchase.order.line (product_id, product_qty, date_planned, qty_received) | Замовлення на закупівлю та матеріали, що мають надійти й будуть доступні в очікувану дату поставки | Odoo → SkyPlanner | Вебхук під час підтвердження або редагування замовлення на закупівлю та те саме періодичне опитування |
| Планові початок і завершення, робочий центр | mrp.workorder.date_start, date_finished, workcenter_id | SkyPlanner → Odoo | У разі зміни графіка, через вебхук SkyPlanner |
| Mobile Confirmations, записи обліку часу | mrp.workcenter.productivity (Time Logs: workcenter_id, workorder_id, date_start, date_end, loss_id) | SkyPlanner → Odoo | Для кожного підтвердження |
| Виготовлена кількість, завершення технологічної операції | qty_producing у виробничому замовленні, потім button_finish; button_mark_done у MO | SkyPlanner → Odoo або виконання в Odoo Shop Floor | Для кожного підтвердження |
Схеми інтеграції
Спочатку — основні дані.
Завантажте робочі центри та календарі, а потім продукцію, BoM і операції, які посилаються на робочі центри. Під час 30-денного пробного періоду ці самі списки завантажуються як експортовані CSV-файли. Інструмент імпорту й експорту Odoo працює в будь-якому поданні списку.
Синхронізація замовлень.
Завантажуйте MO у станах confirmed і progress разом із їхніми виробничими замовленнями. Чернетки MO не завантажуйте або враховуйте як попередній попит. Складальні одиниці з власною специфікацією BoM можуть надходити як окремі дочірні MO, причому Odoo планує кожне MO незалежно. Зіставте їх із підвиробами SkyPlanner, щоб виготовлення складальних одиниць завершувалося до початку виготовлення батьківського виробу.
Зворотний запис графіка.
Коли графік змінюється, вебхук SkyPlanner запускає інтеграцію, яка викликає метод ORM write для кожного відповідного запису mrp.workorder. В Odoo 19.0 це один запит JSON-2 на кожне виробниче замовлення:
“ POST /json/2/mrp.workorder/write Authorization: bearer <api-key> {"ids": [4711], "vals": {"date_start": "2026-11-03 06:00:00", "date_finished": "2026-11-03 09:30:00", "workcenter_id": 7}} “
JSON-2 приймає всі аргументи методу за іменами, а також ids і context, тому аргумент із write(vals) передається як ключ vals. У версіях від 16.0 до 18.0 той самий виклик виконується як execute_kw(db, uid, key, 'mrp.workorder', 'write', [[4711], vals]) через XML-RPC або JSON-RPC, а у 16.0 використовуються ключі date_planned_start і date_planned_finished. Дати й час передавайте в UTC. Щоб запис працював коректно, дотримуйтеся кількох правил:
- Передавайте обидві дати в одному виклику.
- Додавайте
workcenter_idлише тоді, коли рушій вибрав альтернативний верстат. - Записуйте лише поля календарного планування — ніколи не змінюйте кількості чи BoM.
Запис дат змінює час, зарезервований для робочого центру в самій Odoo, тож у поданнях планування Odoo відображається план SkyPlanner.
Дані з виробничого цеху назад до Odoo. Оператори реєструють роботу в SkyPlanner Mobile Confirmations. Для кожного підтвердження інтеграція викликає create для mrp.workcenter.productivity (JSON-2: POST /json/2/mrp.workcenter.productivity/create з vals_list). Вона заповнює workorder_id, workcenter_id, date_start, date_end та loss_id типу Productive, після чого в Odoo відображаються трудовитрати та їхня вартість.
Після завершення технологічної операції інтеграція задає виготовлену кількість і викликає button_finish для виробничого замовлення. Після завершення останнього виробничого замовлення MO готове до виклику button_mark_done. Кожне підтвердження записується лише один раз, а ідентифікатор його запису в Odoo зберігається разом із записом обліку часу в SkyPlanner, тому повторний виклик вебхука ніколи не створює другого запису Time Log.
На підприємствах, які використовують застосунок Enterprise Shop Floor, напрямок зворотний: SkyPlanner зчитує стан виробничого замовлення та qty_produced, а Autopilot автоматично переплановує графік у разі змін на виробництві.
Відповідальність за дані. Зафіксуйте правила до запуску в експлуатацію:
| Дані | Відповідальна система |
|---|---|
| Продукція, BoM, операції, кількості, стан MO | Odoo |
| Послідовність виробничих замовлень, час початку й завершення, вибір робочого центру | SkyPlanner |
| Матриця часу переналагодження, вимоги до інструментів і операторів, альтернативні ресурси | SkyPlanner |
| Календарі робочих центрів і Time Off | Одна система, обрана під час визначення обсягу |
| Time Logs, запаси та собівартість | Odoo, на основі підтверджень зі SkyPlanner |
Планувальники більше не натискають Plan і Unplan в Odoo для MO, які планує SkyPlanner. Інакше Odoo резервує власні часові інтервали замість дат, визначених SkyPlanner.
Типові етапи проєкту
Впровадження зазвичай завершується протягом кількох тижнів від початку налаштування. Перед цим протягом 30-денного безплатного пробного періоду ви працюєте з CSV-файлами, експортованими з вашої Odoo. Сам проєкт охоплює:
- Зіставлення основних даних: моделі та поля Odoo для кожної версії (перевіряйте через
/docабоfields_get), одиниці вимірювання та визначення системи, у якій ведуться календарі й дані Time Off. - Упорядкування даних: перевірте календарі робочих центрів, поля Setup Time і Cleanup Time та встановіть Fixed замість Computed для тривалості операцій BoM.
- Початкове завантаження: продукції, робочих центрів із календарями, BoM та їхніх операцій.
- Синхронізація замовлень і закупівель: підтверджені MO та MO у процесі виконання разом із їхніми виробничими замовленнями, а також рядки
purchase.orderз очікуваними датами надходження. - Зворотний запис графіка: дати та робочі центри в
mrp.workorder, із ротацією ключів API на боці Odoo. - Підтвердження з виробничого цеху: передавання Time Logs і даних про завершення виробничих замовлень назад до Odoo.
- Тестування паралельно з поточним планом, а потім — запуск в експлуатацію.
Підводні камені Odoo
- Перейменовані поля дат. До 16.0 включно поля
date_planned_startіdate_planned_finishedмістили планові дати, аdate_start/date_finished— фактичні. Починаючи з 17.0, планові дати зберігаються вdate_startіdate_finished. Зіставлення, скопійоване з проєкту на 16.0, у версіях 17+ непомітно зчитує фактичні дати як планові. - Дати виробничого замовлення — це резервування часу. У 19.0 поля
date_startіdate_finishedуmrp.workorderобчислюються на основі записуresource.calendar.leaves(leave_id) у календарі робочого центру. Запис дат у виробниче замовлення оновлює це резервування. Ніколи не записуйте дані безпосередньо в таблицю відсутностей. - Розпочаті виробничі замовлення блокують Unplan. Odoo не дозволяє скасувати планування MO, коли «Some work orders have already started» (деякі виробничі замовлення вже розпочато). Під час зворотного запису пропускайте виробничі замовлення у станах
progressабоdoneі переносіть лише ті, які ще не розпочато. - Тривалість змінюється. Для операцій у режимі Computed тривалість визначається за останніми виробничими замовленнями (типово — 10) з коригуванням за Time Efficiency. На пробний період установіть Fixed або враховуйте, що вхідні дані змінюватимуться. Операції зберігаються в кожній BoM окремо, без спільного довідника технологічних маршрутів, тому кожну BoM потрібно впорядкувати окремо.
- Некоректні календарі. Кожному робочому центру потрібен календар робочого часу. Власний планувальник Odoo шукає вільний час на період до 700 днів уперед, а потім зупиняється з повідомленням «Impossible to plan the workorder» (неможливо запланувати виробниче замовлення). Виправте календарі до першого завантаження.
- Одиниці вимірювання.
mrp.bom.lineмає власне полеproduct_uom_id, значення якого може відрізнятися від складської одиниці вимірювання виробу. Перед перевіркою доступності матеріалів виконайте перерахунок одиниць.
Хто налаштовує інтеграцію з Odoo
Кожне підприємство використовує Odoo по-своєму: має власні операції BoM, календарі робочих центрів, альтернативні робочі центри та власні модулі. Команда SkyPlanner має досвід, потрібний для правильного зіставлення даних з урахуванням саме вашої конфігурації.
- Команда SkyPlanner налаштовує інтеграцію під вашу конфігурацію Odoo на початковому етапі та підтримує її після запуску. Вона працює через REST API і вебхуки SkyPlanner та JSON-2 або RPC API Odoo. Це стандартний варіант.
- Ваш партнер Odoo може долучитися. Партнер знає вашу конфігурацію та власні модулі й може розробляти інтеграцію на основі того самого документованого REST API. Цей API дає змогу читати й записувати замовлення, продукцію, матеріали, етапи процесу та записи обліку часу, використовує автентифікацію JWT і має документацію Swagger/OpenAPI.
- Ваші власні розробники можуть зробити те саме — зазвичай у вигляді невеликого проміжного ПЗ поруч з Odoo або модуля на Odoo.sh чи на власних серверах. Для початку достатньо ключа API (посібник з інтеграції), а команда SkyPlanner допоможе за потреби.
Така сама модель уже працює в промисловій експлуатації з іншими ERP. У Laboratory & Allied внутрішня ІТ-команда розробила інтеграцію із SAP Business One переважно самостійно, за допомоги SkyPlanner. Компанія UTU використовує SkyPlanner разом зі своєю ERP NetSuite.
Чому інтеграція окупається
Саме зворотний запис даних робить інтеграцію корисною в щоденній роботі. Коли він працює:
- Виробничі замовлення Odoo отримують реалістичні дати. Рушій Arcturus AI за секунди визначає послідовність усіх відкритих MO, а розраховані дати та вибрані робочі центри записуються в
mrp.workorderі відображаються в поданнях планування Odoo. - Без ручного перепланування. Autopilot автоматично перебудовує графік у разі змін на виробництві, а вебхук передає нові дати до Odoo.
- Зворотний зв’язок із цехом. Оператори реєструють виконану роботу на телефоні чи планшеті за допомогою Mobile Confirmations, Production Timer і Quick Log Mode, а Time Logs надходять до Odoo для обліку запасів і розрахунку собівартості. Планування та виконання ведуться в одному інструменті — як у Community, так і в Enterprise.
- Графік враховує обмеження, яких не враховує Odoo. Матриця часу переналагодження задає час переналагодження для кожної пари виробів залежно від послідовності їх виготовлення. Інструменти — це обмежені виробничі ресурси, спільні для кількох верстатів, а одне виробниче завдання може потребувати кількох операторів одночасно. Якщо основний верстат або працівник недоступний, рушій використовує альтернативні. Дати, записані в
mrp.workorder, враховують усі ці обмеження. - План з урахуванням надходження матеріалів. Наявні запаси та відкриті замовлення на закупівлю в Odoo слугують основою для планування з урахуванням матеріалів. Замовлені компоненти вважаються доступними на дату постачання в PO, а запаси оновлюються, коли PO отримує статус Delivered. Для кожного виробничого завдання перевіряється, що є на складі та що перебуває в дорозі.
Ви можете оцінити графік ще до початку робіт з інтеграції. Почніть 30-денний безплатний пробний період із CSV-файлами та перегляньте власні виробничі замовлення з Odoo на діаграмі Ганта — до 20 робочих центрів, без банківської картки. Вартість — від 199 € на місяць із 5 робочими центрами включно; оплата щомісячна, скасувати можна будь-коли. Вартість інтеграції розраховується заздалегідь з урахуванням ваших процесів і потреб разом із тарифним планом, тож ви бачите повну суму ще до початку роботи. Перегляньте можливості та історії клієнтів або замовте демонстрацію.
Відгуки виробників про SkyPlanner
2 годекономії щотижня
«Завдяки SkyPlanner ми перейшли від планування виробництва в таблицях Excel до оптимізації виробництва в реальному часі».
Kalle Kalliomäki, фахівець із ланцюга постачання
UTU · Електрощити та розподільні пристрої
Планування виробництва заощаджує 2 години робочого часу щотижня, а нова черга завдань надходить на лінію за лічені секунди.
+90%ефективність виробництва
«Ефективність виробництва зросла на 90%».
Abdul Rucyinga, керівник ІТ-відділу
Laboratory & Allied · Фармацевтичне виробництво
Ефективність виробництва зросла на 90%, а підготовка оптимізованого плану на три місяці для всіх робочих центрів займає менш ніж 30 хвилин.
1,000sвиробничих замовлень заплановано автоматично
«Тепер ми по-іншому контролюємо виробництво, а наше розуміння виробничих потужностей вийшло на зовсім інший рівень».
Hannu Ryynänen, генеральний директор
Mamec · Промислові змішувачі, насоси та високотехнологічне контрактне виробництво
Тисячі виробничих замовлень плануються автоматично, а вся організація бачить стан виробництва в реальному часі.
99,2%надійність поставок
«Завдяки SkyPlanner стало легше виявляти вузькі місця, а управління виробництвом стало зрозумілішим».
Toni Tuori, керівник виробництва
Piristeel · Системи безпеки покрівлі та водостічні системи
Цього року надійність поставок досягла 99,2%, а календарне планування дає змогу заощаджувати до чотирьох годин робочого часу щодня.
Поширені запитання
Чи працює інтеграція в Odoo Online?
На тарифі Custom — так, через зовнішній API. Тарифи One App Free та Standard не мають доступу до зовнішнього API, а Standard не підтримує власних модулів. Тому на цих тарифах доступні лише імпорт та експорт CSV/XLSX.
Що використовувати: JSON-2 чи XML-RPC?
В Odoo 19.0 і новіших версіях — JSON-2. Для версій від 16.0 до 18.0 досі потрібні XML-RPC та JSON-RPC, але в Odoo 22 їх заплановано вилучити.
Як графік передається назад до Odoo?
Через метод ORM write для кожного запису mrp.workorder: у 19.0 — POST /json/2/mrp.workorder/write з ids і vals, а у версіях від 16.0 до 18.0 — execute_kw із write через XML-RPC або JSON-RPC. Передаються значення date_start, date_finished (у 16.0 — date_planned_start і date_planned_finished) та, якщо робочий центр змінився, workcenter_id. Odoo відповідно переносить резервування часу робочого центру, тому в поданнях планування Odoo відображаються дати зі SkyPlanner.
Як підтвердження операторів надходять до Odoo?
Як записи Time Logs: інтеграція створює для виробничого замовлення записи mrp.workcenter.productivity із початком, завершенням і причиною втрат типу Productive, а після завершення технологічної операції викликає button_finish. Кожне підтвердження записується лише один раз, тому повторні спроби не дублюють облік часу.
Хто підтримує інтеграцію після запуску?
Команда SkyPlanner налаштовує інтеграцію під час початкового впровадження та підтримує її після запуску, зокрема адаптує до змін у вашій конфігурації Odoo. Якщо інтеграцію створює ваш партнер або ваші розробники, вони спираються на документований REST API та документацію SkyPlanner, а команда допомагає за потреби.
Що відбувається з виробничими замовленнями, виконання яких уже розпочалося?
Не змінюйте їх під час зворотного запису. Odoo не дозволяє скасувати планування MO, якщо виробниче замовлення вже виконується або завершене. SkyPlanner зчитує їхній стан і перебіг виконання та планує решту робіт з урахуванням цих замовлень.
Скільки часу займає інтеграція з Odoo?
Зазвичай інтеграцію завершують протягом кількох тижнів від початку впровадження. Спершу скористайтеся 30-денним пробним періодом із даними, експортованими у CSV. Так ви перевірите графік на власних даних Odoo ще до початку робіт з API.
