Structura datelor Skyplanner #
Înainte de a ne apuca de cronologii, trebuie să discutăm puțin despre structura datelor din Skyplanner și despre cum funcționează lucrurile sub capotă. Toate acestea vor intra în joc mai târziu.
Dacă v-ați integrat datele privind comenzile/ordinele de lucru/locurile de muncă în Skyplanner, cel mai probabil ați utilizat cel puțin aceste puncte finale API:
- phaser-ordine
- phaser-Order-rows
- phaser-jobs
Efectiv, datele introduse în aceste puncte finale sunt reprezentate în interfața de utilizator Skyplanner astfel:
După inserarea comenzilor în Skyplanner, veți dori să le exportați (acest lucru se poate face prin intermediul interfeței utilizator sau al punctului final /phaser-orders/export) în modulul de programare a producției:
Atunci când exportați comenzi, Skyplanner copiază efectiv datele comenzii dintr-un tabel al bazei de date în altul. Astfel, dacă modificați ceva, de exemplu, prin intermediul punctului final /phaser-orders, trebuie să exportați din nou datele pentru a le actualiza în planificarea producției. Acest lucru înseamnă, de asemenea, că pentru a accesa comenzile pe care le vedeți în fereastra de planificare a producției trebuie să utilizați puncte finale API diferite!
Punctele finale “modificate” se prezintă astfel:
Acest lucru este important de știut, deoarece atunci când folosiți punctul final /timelogs pentru a înregistra evenimentele de producție etc., trebuie să folosiți entitățile aferente găsite în punctele finale Production Scheduling!
De exemplu, aveți nevoie de production_planning_job_id (pentru a reitera: production_planning_jobs sunt entitățile accesate de la punctul final /jobs) pentru a posta un nou cronolog:
Puteți găsi ID-ul production_planning_job_de care aveți nevoie fie din punctul final /phaser-jobs:
Sau din punctul final /job:
Crearea de cronologii folosind REST-API #
Realizarea de cronologii pentru Skyplanner prin API utilizează aceleași reguli și sisteme care sunt în interfața utilizator. Prin urmare, ar putea fi benefic să vă familiarizați cu modul în care funcționează sistemul în interfața utilizator înainte de a încerca să îl utilizați prin API.
Bazele timelogului #
Skyplanner are patru tipuri de evenimente timelog:
- shift_begin
- oprită
- continuă
- shift_end
Shift_begin-event este trimis atunci când sarcina este lansată pentru prima dată. Nu trimiteți niciodată mai mult de un eveniment shift_begin pentru fiecare sarcină!
Paused-event întrerupe activitatea.
Continued-event reia o sarcină întreruptă.
Shift_end finalizează lucrarea. Nu trimiteți niciodată mai mult de un eveniment shift_end pentru fiecare sarcină!
Date necesare pentru cronologii:
- ID_persoană
- Poate fi găsit din punctul final /people
- Nu este același lucru cu user_id!
- ID_stație_de_lucru planificată
- Stația de lucru la care se desfășoară activitatea
- Poate fi găsit din /workstations-endpoint
- data_timp
- Momentul în care evenimentul este realizat
- Format: 2024-01-01 10:30:11
Pentru a specifica ce cronolog Skyplanner este legat de cronologul din orice sistem extern pe care îl utilizați, puteți utiliza câmpul external_id . Puteți apoi, de exemplu, să efectuați cereri GET utilizând acest id pentru a găsi un anumit jurnal de bord din Skyplanner.
Începerea unui loc de muncă #
Puteți lansa sarcini de lucru trimițând o solicitare POST ca aceasta către API:
La setarea datelor POST pentru jurnalele de timp, setați workshift_id ca 0 și timelog_finalized ca true
Întreruperea unei lucrări #
Întrerupeți lucrările trimițând o cerere POST după cum urmează:
În jurnalele cronologice de tip pauză, puteți seta valoarea și valoarea defectuoasă (faulty_amount). Rețineți, de asemenea, tipul de cronolog și data_timp.
Continuarea unui loc de muncă #
Iată cum puteți continua un jurnal de timp întrerupt:
Rețineți că dacă încercați să continuați o sarcină care a fost încheiată de un eveniment shift_end, veți primi o eroare.
Încetarea unui loc de muncă #
Iată cum se încheie o lucrare cu ajutorul unui timelog shift_end:
În shift_end-events puteți da valorile amount și faulty_amount la fel ca în paused-events. Rețineți că, dacă încercați să efectuați un shift_end-event pentru un job care nu rulează, veți primi o eroare.
Actualizarea cronologiei #
Puteți actualiza datele timelog prin trimiterea de cereri PUT către punctul final /timelogs, astfel:
Rețineți că trebuie să aveți atât datele beginTimelog , cât și cele endTimelog pentru a efectua o actualizare. Cronologiile în Skyplanner sunt stocate astfel: fiecare cronolog “complet” (cronolog care are atât un început, cât și un sfârșit (de exemplu, shift_begin/continued & paused/shift_end) are o entitate separată pentru început și sfârșit.
Acestea sunt împerecheate de valoarea begin_id găsită în endlog. În exemplul de mai sus, beginTimelog are valoarea id 1 și, prin urmare, endTimelog are valoarea begin_id 1.
De asemenea, trebuie să furnizați valorile person_id și endTimelog de fiecare dată când faceți o cerere de actualizare, chiar dacă nu le modificați.
Modalități alternative de a realiza cronologii #
Iată câteva modalități alternative prin care vă puteți conecta la locurile de muncă utilizând API.
Logfull #
Dacă doriți să trimiteți atât cronologiile de început, cât și cele de sfârșit într-o singură cerere, puteți utiliza punctul /timelogs/log-full -endpoint, astfel:
Observați modul în care sumele sunt trimise aici: prima valoare “amount” denotă suma defectă, iar cea de-a doua, suma. Această cerere creează entitățile beginlog și endlog într-o singură cerere.
Quicklog #
“Quicklogging” la o sarcină o finalizează într-o singură cerere, stabilește cantitatea de produse finalizată pentru a corespunde valorii stabilite în elementul de comandă. Quicklogging se realizează prin utilizarea punctului final /timelogs/quick-log:
Rețineți că aici trebuie să furnizați doar ID_job_de_planificare_producție, ID_stație_de_lucru_planificată și ID_persoană. Valorile timp și sumă sunt completate automat. Rețineți, de asemenea, că lucrările blocate rapid sunt întotdeauna finalizate cu evenimentul shift_end, astfel încât nu mai este posibilă înregistrarea ulterioară după blocarea rapidă!
