Структура даних Skyplanner #
Перш ніж ми зануримося в хронологи, нам потрібно трохи поговорити про структуру даних у Skyplanner і про те, як все працює під капотом. Все це стане в нагоді пізніше.
Якщо ви інтегрували дані про замовлення/замовлення/завдання в Skyplanner, то, швидше за все, використовували принаймні ці API-кінцеві точки:
- фазерні замовлення
- фазерні ряди
- фазерні роботи
Фактично, дані, вставлені в ці кінцеві точки, представлені в інтерфейсі Skyplanner таким чином:
Після додавання замовлень до Skyplanner вам потрібно буде експортувати їх (це можна зробити через інтерфейс або за допомогою файлу /phaser-orders/export-endpoint) до модуля “Планування виробництва”:
При експорті замовлень Skyplanner ефективно копіює дані замовлення з однієї таблиці бази даних в іншу. Тому, якщо ви щось змінюєте, наприклад, через /phaser-orders -endpoint, вам потрібно знову експортувати дані, щоб оновити їх у Плануванні виробництва. Це також означає, що для доступу до замовлень, які ви бачите у вікні Планування виробництва, вам доведеться використовувати різні API-кінцеві точки!
“Змінені” кінцеві точки виглядають так:
Це важливо знати, оскільки при використанні /timelogs -кінцевого пункту для реєстрації виробничих подій і т.д. ви повинні використовувати пов’язані сутності, знайдені в Production Scheduling -кінцевих пунктах!
Наприклад, вам потрібен ідентифікатор завдання_планування_виробництва (повторюємо: завдання_планування_виробництва – це сутності, доступ до яких здійснюється з /jobs -кінцевої точки) для того, щоб відправити новий часовий графік:
Ви можете знайти потрібний вам ідентифікатор job_planning_job_id з кінцевої точки /phaser-jobs -endpoint:
Або з кінцевої точки /job:
Створення таймлогів за допомогою REST-API #
Створення таймлогів у Skyplanner через API використовує ті ж правила і системи, що і в інтерфейсі користувача. Тому може бути корисно ознайомитися з тим, як працює система в інтерфейсі, перш ніж намагатися використовувати її через API.
Основи хронології #
Skyplanner має чотири типи подій у розкладі:
- shift_begin
- призупинився
- продовжував
- shift_end
Подія Shift_begin-event надсилається при першому запуску роботи. Ніколи не надсилайте більше однієї події shift_begin для кожного завдання!
Пауза-подія призупиняє роботу.
Безперервна подія відновлює роботу, яку було призупинено.
Shift_end завершує роботу. Ніколи не надсилайте більше однієї події shift_end для кожного завдання!
Необхідні дані для часових діаграм:
- person_id
- Можна знайти за адресою /people-endpoint
- Не те саме, що user_id!
- запланований_id_робочої_станції
- Робоча станція, на якій виконується робота
- Можна знайти в /workstations-endpoint
- дата_час
- Момент часу, коли подія завершена
- Формат: 2024-01-01 10:30:11
Для того, щоб вказати, до якого хронолога Skyplanner прив’язаний хронолог із будь-якої зовнішньої системи, яку ви використовуєте, ви можете скористатися полем external_id . Ви можете, наприклад, робити GET-запити, використовуючи цей ідентифікатор, щоб знайти певний часовий журнал у Skyplanner.
Початок роботи #
Ви можете запустити завдання, відправивши POST-запит до API ось так:
Під час налаштування POST-даних для часових журналів встановіть workshift_id як 0, а timelog_finalized як true
Призупинення роботи #
Призупиніть роботу, надіславши POST-запит ось так:
У таймлогах типу paused ви можете задати суму та faulty_amount. Зверніть увагу також на тип часового журналу та date_time.
Продовження роботи #
Ось як продовжити призупинений хронолог:
Зверніть увагу, що якщо ви спробуєте продовжити роботу, яка була завершена подією shift_end, ви отримаєте помилку.
Закінчення роботи #
Ось як завершити роботу за допомогою таймлагу shift_end:
У shift_end-події ви можете вказати значення amount і faulty_amount так само, як і в paused-події. Зверніть увагу, що якщо ви спробуєте створити shift_end-подію для завдання, яке не виконується, ви отримаєте помилку.
Оновлення таймлогів #
Ви можете оновити дані журналу, надіславши PUT-запити до кінцевої точки /timelogs-endpoint, ось так:
Зауважте, що для оновлення ви повинні мати дані як beginTimelog , так і endTimelog . Хронологи у Skyplanner зберігаються таким чином: кожен “повний” (тобто такий, що має початок і кінець (наприклад, shift_begin/continued & paused/shift_end)) хронолог має окремий об’єкт для початку і кінця.
Вони об’єднані значенням begin_id , яке міститься у endlog. У наведеному вище прикладі beginTimelog має значення id, рівне 1, і, відповідно, endTimelog має значення begin_id , рівне 1.
Ви також повинні вказувати значення person_id і endTimelog при кожному запиті на оновлення, навіть якщо ви їх не змінюєте.
Альтернативні способи створення таймлогів #
Ось кілька альтернативних способів входу до ваших завдань за допомогою API.
Logfull #
Якщо ви хочете надіслати як початковий, так і кінцевий хронологи в одному запиті, ви можете використати /timelogs/log-full -endpoint, як це зроблено нижче:
Зверніть увагу, як тут надсилаються суми: перше значення “amount” позначає помилкову суму, а друге – правильну. Цей запит створює сутності beginlog і endlog одним запитом.
Quicklog #
“Quicklogging” до завдання завершує його за один запит, встановлює виконану кількість товарів у відповідність до значення, встановленого в позиції замовлення. Квіклог виконується за допомогою параметра /timelogs/quick-log -endpoint:
Зверніть увагу, що тут потрібно вказати лише ідентифікатор робочого місця, ідентифікатор робочого місця та ідентифікатор особи. Значення часу і кількості заповнюються автоматично. Також зауважте, що завдання з швидким журналюванням завжди завершуються подією shift_end-event, тому подальше журналювання після quicklog неможливе!
