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

Для інтеграції S/4HANA надає офіційно випущені сервіси OData, перелічені в SAP Business Accelerator Hub (api.sap.com). Інтеграція календарного планування працює через сервіси OData V2. IDocs і BAPIs також доступні, але в цьому посібнику використовуються офіційно випущені OData API.

Автентифікація залежно від редакції

• Локальне розгортання та Private Edition. Сервіси активуються в SAP Gateway за допомогою транзакції /IWFND/MAINT_SERVICE. Користувачеві інтеграції потрібні відповідні об’єкти авторизації, наприклад C_AFRU_AWK для підтверджень, C_AFKO_AWK для позицій руху матеріалів, що проводяться разом із ними, та M_PLAF_ORG для планових замовлень.
• Public Edition. Доступ до сервісів надається лише через комунікаційні угоди. Дотримуючись інструкцій SAP з налаштування вхідного обміну, створіть комунікаційного користувача, комунікаційну систему та комунікаційну угоду в застосунку Communication Arrangements на основі комунікаційного сценарію SAP (SAP_COM_xxxx). Сценарій визначає, які сервіси та способи автентифікації будуть доступні:

– на основі токенів: схеми автентифікації з bearer-токенами OAuth, SAML або OpenID Connect, із передаванням ідентичності (principal propagation) для роботи від імені бізнес-користувача – клієнтський сертифікат – базова автентифікація з технічним користувачем для обміну даними

SAP рекомендує автентифікацію за токеном або сертифікатом.

З боку SkyPlanner використовується REST API з автентифікацією JWT, описаний у Swagger/OpenAPI (довідник API). Тож проміжне ПЗ забезпечує автентифікацію SAP з одного боку та роботу з JWT — з іншого.

API для календарного планування виробництва

Сервіс	Використовувані сутності та дії	Призначення
API_PRODUCTION_ORDER_2_SRV (Production Order, Version 2)	A_ProductionOrder_2, A_ProductionOrderItem_2, A_ProductionOrderOperation_2, A_ProductionOrderComponent_2, A_ProductionOrderStatus_2, A_ProductionRsceTools_2; дії ReleaseOrder, ReleaseOperation, ScheduleProductionOrderOperation	Замовлення, технологічні операції, компоненти, PRTs, статус, зворотний запис графіка
API_WORK_CENTERS	A_WorkCenters, A_WorkCenterAllCapacity_2, A_WorkCenterCapacity, A_WorkCenterCapacityInterval_2, A_WorkCenterCapacityShift_2, A_WorkCenterCapPerBucket	Робочі центри, категорії потужностей, інтервали та зміни
API_PRODUCTION_ROUTING	ProductionRoutingHeader, ProductionRoutingSequence, ProductionRoutingOperation, ProductionRoutingSubOperation, ProductionRoutingMatlAssgmt, ProductionRoutingOpCompAlloc	Типові технологічні маршрути для планування до створення замовлень
API_BILL_OF_MATERIAL_SRV;v=2	MaterialBOM, MaterialBOMItem, MaterialBOMSubItem	Багаторівнева структура виробу
API_PRODUCT_SRV (Product Master A2X)	A_Product	Матеріали (в API — Product). Наразі SAP рекомендує API Product (Version 2) для більшості сутностей продукту
API_PLANNED_ORDERS	A_PlannedOrder, A_PlannedOrderComponent, A_PlannedOrderCapacity	Результати MRP Live до перетворення планових замовлень
API_MATERIAL_STOCK_SRV	A_MaterialStock, A_MatlStkInAcctMod	Запаси за заводами та місцями зберігання для визначення доступності матеріалів
API_PURCHASEORDER_PROCESS_SRV	A_PurchaseOrder, A_PurchaseOrderItem	Відкриті замовлення на закупівлю матеріалів, що мають надійти
API_PROD_ORDER_CONFIRMATION_2_SRV	ProdnOrdConf2, ProdnOrdConfMatlDocItm; дії GetConfProposal, GetGdsMvtProposal, CancelProdnOrdConf	Підтвердження та дані про рух матеріалів із виробничого цеху

В API виробничих замовлень технологічні операції ідентифікуються парою ключів OrderInternalBillOfOperations і OrderIntBillOfOperationsItem, а не номером операції, який бачить планувальник. Дія GetConfProposal в API підтверджень звертається до тієї самої операції за OrderID та OrderOperation. Зберігайте в SkyPlanner і внутрішні ключі, і номер операції вже під час першого завантаження.

Події

S/4HANA генерує бізнес-події Production Order Created та Production Order Changed, що містять ManufacturingOrder, ProductionOrder, ProductionOrderType і ProductionPlant у корисному навантаженні. Воно містить лише ключі, тому інтеграція повторно зчитує замовлення та його операції. Подія Changed виникає за кожної зміни замовлення, тож об’єднуйте часті спрацьовування за допомогою debounce. У зворотному напрямку вебхуки SkyPlanner надсилають сповіщення в реальному часі, коли змінюється графік або стан виробничого завдання.

Початок роботи через файли

Для пробного використання експортуйте виробничі замовлення та робочі центри зі звітів-списків S/4HANA у форматі Excel або CSV та імпортуйте їх у SkyPlanner. Так ви перевірите графік ще до початку налаштування Gateway або параметрів обміну даними.

1. Завантаження основних даних. Завантажте матеріали, BOM, робочі центри з інтервалами доступності потужностей і змінами, а також технологічні маршрути. На цьому етапі визначте, яка система відповідатиме за зміни. Практичний варіант розподілу: заводський календар залишається в S/4HANA, а детальні графіки змін, відсутності та понаднормові години ведуться у SkyPlanner, де планувальники коригують їх щодня.

2. Синхронізація замовлень. Підпишіться на Production Order Created/Changed або, якщо бізнес-події не налаштовано, опитуйте A_ProductionOrder_2 за часовою міткою зміни. Фільтруйте за заводом, типом замовлення та статусом. Надсилайте замовлення одразу після створення, щоб SkyPlanner міг планувати заздалегідь, а після включення до графіка SkyPlanner деблокуйте їх у S/4HANA (ReleaseOrder або ReleaseOperation).

3. Зворотний запис графіка. Коли вебхук SkyPlanner повідомляє про зміну графіка, інтеграція викликає ScheduleProductionOrderOperation в API_PRODUCTION_ORDER_2_SRV для кожної зміненої операції. Передаються такі дані:

• ManufacturingOrder, OrderInternalBillOfOperations і OrderIntBillOfOperationsItem як ключі
• OpSchedulingMode зі значенням F (пряме планування), із початком за графіком SkyPlanner у OpSchedldStartDate та OpSchedldStartTime
• OpSchedulingStatus зі значенням DISP (диспетчеризація) та обов’язковий параметр OpSchedulingStrategy зі значенням M
• ETag у if-match

Усі операції одного замовлення передаються в одному наборі змін у послідовності, визначеній SkyPlanner. Так S/4HANA розміщує весь план замовлення в графіку за один виклик. Режим K ніколи не використовується: він зберігає початкові дати операцій та ігнорує передані дати.

SkyPlanner визначає тривалість операцій за тими самими нормативними значеннями технологічних маршрутів і формулами потужності робочих центрів, що й S/4HANA. Тому дата завершення, яку S/4HANA обчислює на основі переданої дати початку, узгоджується з планом SkyPlanner. Після кожного набору змін інтеграція повторно зчитує операції та позначає всі розбіжності в датах, щоб планувальник побачив їх до наступної зміни.

4. Підтвердження з виробничого цеху. Кожен запис обліку часу з Mobile Confirmations або Production Timer стає підтвердженням у S/4HANA. Вебхук SkyPlanner запускає надсилання ProdnOrdConf2 із кількістю придатної продукції, браку та часом виконання робіт. Спочатку інтеграція викликає GetConfProposal, щоб S/4HANA запропонувала кількості, роботи, дати та дані персоналу. GetGdsMvtProposal пропонує рух матеріалів.

Очікувані надходження матеріалів. Відкриті замовлення на закупівлю входять до вхідної синхронізації. SkyPlanner вважає замовлений матеріал доступним на очікувану дату поставки, зазначену в замовленні на закупівлю. Завдання, що очікують на закуплені компоненти, плануються на день надходження матеріалу, а не блокуються через поточний рівень запасів.

S/4HANA залишається джерелом достовірних даних про надходження: після проведення надходження товару запас збільшується, а відкрита кількість у позиції замовлення на закупівлю зменшується. Наступна синхронізація оновлює запаси у SkyPlanner і встановлює повністю отриманому замовленню статус Delivered. Після часткового надходження решта відкритої кількості залишається очікуваним надходженням на дату відповідного рядка графіка поставок. Обробку замовлень на закупівлю описано в документації SkyPlanner.

5. Розподіл відповідальності за дані. S/4HANA відповідає за кількості, BOM, технологічний маршрут, калькуляцію собівартості та статус. SkyPlanner відповідає за послідовність, призначення робочих центрів і дати операцій. Ніколи не дозволяйте обом системам записувати дані в одне й те саме поле. Якщо планувальники й далі переміщують операції в Capacity Scheduling Board, визначте, які зміни мають пріоритет. Або наступна синхронізація замовлень переносить їхні зміни до SkyPlanner, або цей робочий центр залишається поза сферою планування SkyPlanner.

• Зворотний запис виконується викликом дії з ETag. Задокументований спосіб календарного планування операції — ScheduleProductionOrderOperation, а не PATCH для A_ProductionOrderOperation_2. Режим F планує вперед від початку, а B — назад від завершення; натомість K і S зберігають наявні дати та ігнорують ваші. ETag у if-match формується з LastChangeDateTime замовлення (YYYYMMDDHHMMSS), тому будь-яка зміна замовлення робить його застарілим. Реалізуйте зчитування перед записом і чергу повторних спроб.
• Дані про потужність містяться не в заголовку робочого центру. Доступна потужність визначається категорією потужності (001 — устаткування, 002 — персонал), заводським календарем, а також інтервалами та змінами, що перевизначають його. За формулами потужності на основі нормативних значень технологічного маршруту розраховують потребу в потужностях для підготовки, обробки та завершальних робіт. Зчитуйте A_WorkCenterCapacityInterval_2 і сутності змін та узгодьте, як за цими формулами визначати тривалість операцій у SkyPlanner.
• Нормативні значення потребують упорядкування. У технологічних маршрутах, які ведуть для калькуляції собівартості, часто зазначають усереднений час налагодження або відносять його до неправильної категорії потужностей.
• Правила підтвердження суворі. SAP рекомендує пакетні виклики для масового проведення. Набір змін виконується за принципом «усе або нічого», тому один некоректний запис обліку часу блокує решту набору. Скасування в пакеті мають виконуватися у зворотному порядку ConfirmationCount. Не можна поєднувати різні типи підтверджень в одному замовленні, проводити рух матеріалів без підтвердження або підтверджувати операції, тригерні точки яких потребують діалогового вікна.
• Перевірте, чи активовано PP/DS. Для вбудованого PP/DS потрібні дія Customizing Activate Advanced Planning and Scheduling та SAP HANA integrated liveCache. SAP продає його як окремий продукт — SAP S/4HANA Manufacturing for planning and scheduling. Якщо він активний, визначте для кожного матеріалу, яка система виконує планування: матеріали з ознакою розширеного планування належать до сфери PP/DS. Щодо API планових замовлень SAP також зазначає: “Automatic integration to PP/DS is not enabled from this API.” (Автоматичну інтеграцію з цією системою через цей API не ввімкнено.)
• Одиниці вимірювання. Кількості в операціях, базові кількості технологічних маршрутів та одиниці підтвердження можуть відрізнятися. Явно виконуйте перерахунок в одиницю вимірювання операції, а не в базову одиницю матеріалу.
• Відмінності між редакціями. У SAP Learning показано, як класичну таблицю планування CM21/CM22 замінюють Manage Work Center Capacity, Capacity Scheduling Table і Capacity Scheduling Board. У Public Edition API доступні лише через сценарії обміну даними, а версії сервісів можуть відрізнятися від локальної інсталяції. API технологічних маршрутів не дає змоги видаляти маршрути або оновлювати прив’язки матеріалів. Під час визначення обсягу команда SkyPlanner фіксує версії сервісів для системи кожного клієнта, спираючись на запис API Business Accelerator Hub для відповідного випуску.
• Обмеження, яких немає в технологічних маршрутах. Переналагодження, що залежать від послідовності, конфлікти використання інструментів та операції за участю кількох операторів ведіть у SkyPlanner, а не в нормативних значеннях технологічних маршрутів. Матриця часу налагодження містить час переналагодження для кожної пари продуктів. Інструменти з PRT замовлення є обмеженими ресурсами: одночасно їх може використовувати лише один робочий центр. Водночас операція може потребувати кількох працівників одночасно.