Struktura danych Skyplanner #
Zanim zagłębimy się w dzienniki czasowe, musimy omówić nieco strukturę danych w Skyplanner i sposób działania pod maską. Wszystko to zostanie omówione później.
Jeśli zintegrowałeś swoje dane dotyczące zamówień/zleceń/zadań w Skyplanner, najprawdopodobniej korzystałeś przynajmniej z tych punktów końcowych API:
- phaser-orders
- phaser-Order-rows
- phaser-jobs
W rzeczywistości dane wprowadzane do tych punktów końcowych są reprezentowane w interfejsie użytkownika Skyplanner w następujący sposób:
Po wstawieniu zamówień do Skyplannera należy je wyeksportować (można to zrobić za pośrednictwem interfejsu użytkownika lub punktu końcowego /phaser-orders/export-endpoint) do modułu planowania produkcji:
Podczas eksportowania zamówień Skyplanner skutecznie kopiuje dane zamówienia z jednej tabeli bazy danych do drugiej. Jeśli więc zmienisz coś, na przykład za pomocą punktu końcowego /phaser-orders, musisz ponownie wyeksportować dane, aby zaktualizować je w Harmonogramie produkcji. Oznacza to również, że aby uzyskać dostęp do zamówień widocznych w oknie harmonogramu produkcji, należy użyć różnych punktów końcowych API!
“Zmienione” punkty końcowe wyglądają następująco:
Warto o tym wiedzieć, ponieważ podczas korzystania z punktu końcowego /timelogs do rejestrowania zdarzeń produkcyjnych itp. należy używać powiązanych jednostek znajdujących się w punktach końcowych harmonogramu produkcji!
Na przykład, potrzebujesz production_planning_job_id (aby powtórzyć: production_planning_jobs to jednostki dostępne z punktu końcowego /jobs), aby POST nowy dziennik czasu:
Potrzebny identyfikator production_planning_job_id można znaleźć w punkcie końcowym /phaser-jobs:
Lub z punktu końcowego /job:
Tworzenie dzienników czasu przy użyciu interfejsu REST-API #
Tworzenie dzienników czasowych do Skyplanner przez API wykorzystuje te same zasady i systemy, które są w interfejsie użytkownika. Warto więc zapoznać się z działaniem systemu w interfejsie użytkownika przed podjęciem próby korzystania z niego za pośrednictwem API.
Podstawy dziennika czasu #
Skyplanner posiada cztery typy zdarzeń dziennika czasu:
- shift_begin
- wstrzymany
- cd.
- shift_end
Zdarzenie Shift_begin jest wysyłane, gdy zadanie jest uruchamiane po raz pierwszy. Nigdy nie wysyłaj więcej niż jednego zdarzenia shift_begin dla każdego zadania!
Wstrzymane – zdarzenie wstrzymuje zadanie.
Zdarzenie kontynuowane wznawia wstrzymane zadanie.
Shift_end kończy zadanie. Nigdy nie wysyłaj więcej niż jednego zdarzenia shift_end dla każdego zadania!
Wymagane dane dla dzienników czasowych:
- person_id
- Można go znaleźć w punkcie końcowym /people
- To nie to samo co user_id!
- planned_workstation_id
- Stanowisko pracy, na którym wykonywane jest zadanie
- Można go znaleźć w punkcie końcowym /workstations
- date_time
- Moment, w którym zdarzenie jest wykonywane
- Format: 2024-01-01 10:30:11
Aby określić, który dziennik czasu Skyplanner jest powiązany z dziennikiem czasu z dowolnego używanego systemu zewnętrznego, można użyć pola external_id . Następnie można na przykład wysyłać żądania GET przy użyciu tego identyfikatora w celu znalezienia określonego dziennika czasowego ze Skyplanner.
Rozpoczęcie pracy #
Zadania można uruchamiać, wysyłając do interfejsu API żądanie POST w następujący sposób:
Podczas ustawiania danych POST dla dzienników czasowych ustaw workshift_id na 0 i timelog_finalized na true.
Wstrzymywanie zadania #
Wstrzymaj zadania, wysyłając żądanie POST w następujący sposób:
W dziennikach czasu typu wstrzymanego można ustawić kwotę i faulty_amount. Należy również zwrócić uwagę na typ dziennika czasu i date_time.
Kontynuacja pracy #
Oto jak kontynuować wstrzymany dziennik czasu:
Należy pamiętać, że próba kontynuowania zadania, które zostało zakończone przez zdarzenie shift_end, spowoduje wyświetlenie błędu.
Zakończenie pracy #
Oto jak zakończyć zadanie za pomocą dziennika czasu shift_end:
W shift_end-events można podać wartości amount i faulty_amount , tak jak w paused-events. Należy pamiętać, że próba wykonania zdarzenia shift_end dla zadania, które nie jest uruchomione, spowoduje wyświetlenie błędu.
Aktualizacja dzienników czasowych #
Dane dziennika czasu można aktualizować, wysyłając żądania PUT do punktu końcowego /timelogs-endpoint w następujący sposób:
Należy pamiętać, że aby wykonać aktualizację, trzeba mieć ustawione zarówno dane beginTimelog , jak i endTimelog . Dzienniki czasowe w Skyplanner są przechowywane w następujący sposób: każdy “pełny” (dziennik czasowy, który ma zarówno początek, jak i koniec (np. shift_begin/continued & paused/shift_end) dziennik czasowy ma oddzielną jednostkę dla początku i końca.
Są one sparowane przez wartość begin_id znalezioną w endlog. W powyższym przykładzie beginTimelog ma wartość id równą 1, a zatem jego endTimelog ma wartość begin_id równą 1.
Musisz również podać wartości person_id i endTimelog za każdym razem, gdy wykonujesz żądanie aktualizacji, nawet jeśli ich nie zmieniasz.
Alternatywne sposoby tworzenia dzienników czasowych #
Oto kilka alternatywnych sposobów logowania się do zadań przy użyciu interfejsu API.
Logfull #
Jeśli chcesz wysłać zarówno początkowe, jak i końcowe dzienniki czasowe w jednym żądaniu, możesz użyć punktu końcowego /timelogs/log-full, jak poniżej:
Zwróć uwagę, w jaki sposób przesyłane są tutaj kwoty: pierwsza wartość “amount” oznacza błędną kwotę, a druga kwotę. To żądanie tworzy encje beginlog i endlog w jednym żądaniu.
Quicklog #
“Szybkie logowanie” do zadania kończy je w jednym żądaniu, ustawia ukończoną ilość produktów, aby odpowiadała wartości ustawionej w pozycji zamówienia. Szybkie logowanie odbywa się za pomocą punktu końcowego /timelogs/quick-log:
Należy pamiętać, że tutaj wystarczy podać tylko production_planning_job_id, planned_workstation_id i person_id. Wartości czasu i kwoty są wypełniane automatycznie. Należy również pamiętać, że szybkie rejestrowanie zadań jest zawsze zakończone zdarzeniem shift_end, więc dalsze rejestrowanie nie jest możliwe po szybkim rejestrowaniu!