--- title: Хронологія подій description: "#### Структура даних Skyplanner Перш ніж ми зануримося в таймлоги, нам потрібно трохи обговорити структуру даних у Skyplanner і те, як все працює під капотом. Все це стане в нагоді пізніше. Якщо ви інтегрували дані про замовлення/замовлення/завдання в Skyplanner, то,…" url: "https://skyplanner.ai/uk/docs/%d1%85%d1%80%d0%be%d0%bd%d0%be%d0%bb%d0%be%d0%b3%d1%96%d1%8f-%d0%bf%d0%be%d0%b4%d1%96%d0%b9/" updated: "2025-10-07" category: Інтеграції tags: - API - Інтеграція --- # Хронологія подій #### Структура даних Skyplanner Перш ніж ми зануримося в таймлоги, нам потрібно трохи обговорити структуру даних у Skyplanner і те, як все працює під капотом. Все це стане в нагоді пізніше. Якщо ви інтегрували дані про замовлення/замовлення/завдання в Skyplanner, то, швидше за все, використовували принаймні ці API-кінцеві точки: - фазерні замовлення - фазерні ряди - фазерні роботи Фактично, дані, вставлені в ці кінцеві точки, представлені в інтерфейсі Skyplanner таким чином: ![](https://skyplanner.ai/wp-content/uploads/2025/03/image-25-1024x714.png) **Рис. 1.** Замовлення (фазерні замовлення) ![](https://skyplanner.ai/wp-content/uploads/2025/03/image-26-1024x715.png) **Рис. 2.** Елементи замовлення (phaser-order-rows (червоний)), етапи процесу (phaser-jobs (зелений)) Після додавання замовлень до Skyplanner вам потрібно буде **експортувати їх** (це можна зробити через інтерфейс або за допомогою файлу /phaser-orders/export-endpoint) до модуля "Планування виробництва": ![](https://skyplanner.ai/wp-content/uploads/2025/03/image-27-1024x596.png) **Рис. 3.** Експорт через інтерфейс користувача ![](https://skyplanner.ai/wp-content/uploads/2025/03/image-28-1024x597.png) **Рис. 4.** Експортоване замовлення в Плануванні виробництва При експорті замовлень Skyplanner ефективно копіює дані замовлення з однієї таблиці бази даних в іншу. Тому, якщо ви щось змінюєте, наприклад, через /phaser-orders -endpoint, вам потрібно знову експортувати дані, щоб оновити їх у Плануванні виробництва. Це також означає, що для доступу до замовлень, які ви бачите у вікні Планування виробництва, вам доведеться використовувати різні API-кінцеві точки! "Змінені" кінцеві точки виглядають так: - /phaser-orders → /orders - /phaser-order-rows → /order-rows - /phaser-jobs → /jobs Це важливо знати, оскільки при використанні /timelogs -кінцевого пункту для реєстрації виробничих подій і т.д. **ви повинні використовувати пов'язані сутності, знайдені в Production Scheduling -кінцевих пунктах!** Наприклад, вам потрібен **ідентифікатор завдання_планування_виробництва**(повторюємо: завдання_планування_виробництва - це сутності, доступ до яких здійснюється з /jobs -кінцевої точки) для того, щоб відправити новий часовий графік: ![](https://skyplanner.ai/wp-content/uploads/2025/03/image-29.png) **Рис. 5.** Хронологічний POST запит Ви можете знайти потрібний вам ідентифікатор job_planning_job_id з кінцевої точки /phaser-jobs -endpoint: ![](https://skyplanner.ai/wp-content/uploads/2025/03/image-30.png) **Рис 6.** GET-запит на завдання фазера (червоний - phaser_job_id, **НЕ ВИКОРИСТОВУВАТИ В ТАЙМЛОГАХ**) Або з кінцевої точки /job: ![](https://skyplanner.ai/wp-content/uploads/2025/03/image-31.png) **Рис. 7.** /job GET запит #### Створення таймлогів за допомогою 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. ![](https://skyplanner.ai/wp-content/uploads/2025/03/image-32-1024x438.png) **Рис. 8.** External_id у часових журналах #### Початок роботи Ви можете запустити завдання, відправивши POST-запит до API ось так: ![](https://skyplanner.ai/wp-content/uploads/2025/03/image-33.png) **Рис. 9.** Хронологія Shift_begin Під час налаштування POST-даних для часових журналів встановіть **workshift_id**як 0, а **timelog_finalized**як **true** #### Призупинення роботи Призупиніть роботу, надіславши POST-запит ось так: ![](https://skyplanner.ai/wp-content/uploads/2025/03/image-34.png) **Рис. 10.** Призупинений хронолог У таймлогах типу paused ви можете задати **суму**та **faulty_amount**. Зверніть увагу також на **тип**часового журналу та **date_time**. #### Продовження роботи Ось як можна продовжити призупинений хронолог: ![](https://skyplanner.ai/wp-content/uploads/2025/03/image-35.png) **Рис. 11.** Продовження хронології Зверніть увагу, що якщо ви спробуєте продовжити роботу, яка була завершена подією shift_end, ви отримаєте помилку. #### Закінчення роботи Ось як завершити роботу за допомогою таймлагу shift_end: ![](https://skyplanner.ai/wp-content/uploads/2025/03/image-36.png) **Рис. 12.** Хронологія Shift_end У shift_end-події ви можете вказати значення **amount**і **faulty_amount**так само, як і в paused-події. Зверніть увагу, що якщо ви спробуєте створити shift_end-подію для завдання, яке не виконується, ви отримаєте помилку. #### Оновлення таймлогів Ви можете оновити дані журналу, надіславши PUT-запити до кінцевої точки /timelogs-endpoint, ось так: ![](https://skyplanner.ai/wp-content/uploads/2025/03/image-37.png) **Рис. 13.** Редагування хронологів Зауважте, що для оновлення ви повинні мати дані як **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, як це зроблено нижче: ![](https://skyplanner.ai/wp-content/uploads/2025/03/image-38.png) **Рис. 14.** Запит повного журналу Зверніть увагу, як тут надсилаються суми: перше значення "amount" позначає **помилкову** **суму**, а друге - правильну. Цей запит створює сутності beginlog і endlog одним запитом. ##### Quicklog "Quicklogging" до завдання завершує його за один запит, встановлює виконану кількість товарів у відповідність до значення, встановленого в позиції замовлення. Квіклінг виконується за допомогою кінцевого параметра **/timelogs/quick-log**: ![](https://skyplanner.ai/wp-content/uploads/2025/03/image-39.png) **Мал. 15.** Швидке ведення журналу Зверніть увагу, що тут потрібно вказати лише **ідентифікатор** **робочого місця, ідентифікатор робочого місця**та ідентифікатор **особи**. Значення часу і кількості заповнюються автоматично. Також зауважте, що завдання з швидким журналюванням завжди завершуються подією shift_end-event, тому подальше журналювання після quicklog неможливе!