Skyplanner datastruktur #
Innan vi dyker ner i tidsloggarna måste vi diskutera lite om datastrukturen i Skyplanner och hur saker och ting fungerar under huven. Allt detta kommer att spela in senare.
Om du har integrerat dina order-/arbetsorder-/jobbdata i Skyplanner har du troligen använt åtminstone dessa API-endpoints:
- phaser-order
- phaser-ordning-rader
- phaser-jobb
I praktiken representeras data som matas in i dessa ändpunkter i Skyplanner-gränssnittet på följande sätt:
När du har infogat dina beställningar i Skyplanner vill du exportera dem (detta kan göras via användargränssnittet eller / phaser-orders/export-endpoint) till produktionsschemaläggningsmodulen:
Vid export av order kopierar Skyplanner i praktiken orderdata från en databastabell till en annan. Så om du ändrar något, till exempel via /phaser-orders -ändpunkten, måste du exportera data igen för att uppdatera dem i produktionsplaneringen. Detta innebär också att du måste använda olika API-endpoints för att komma åt de order som du ser i fönstret för produktionsplanering!
De “ändrade” slutpunkterna ser ut så här:
- /phaser-order → /order
- /phaser-order-rader → /order-rader
- /phaser-jobb → /jobb
Detta är viktigt att veta, för när du använder /timelogs -endpoint för att logga dina produktionshändelser etc. måste du använda de relaterade enheterna som finns i Production Scheduling -endpoints!
Du behöver till exempel production_planning_job_id (för att upprepa: production_planning_jobs är de enheter som nås från /jobs -endpoint) för att POSTA en ny tidslogg:
Du kan hitta det production_planning_job_id du behöver antingen från /phaser-jobs -endpoint:
Eller från /job -slutpunkten:
Skapa tidsloggar med hjälp av REST-API #
För att skapa tidsloggar till Skyplanner via API:et används samma regler och system som i användargränssnittet. Det kan därför vara bra att bekanta sig med hur systemet fungerar i användargränssnittet innan man försöker använda det via API:et.
Grunderna i tidslogg #
Skyplanner har fyra typer av händelser i tidsloggen:
- skift_början
- pausad
- fortsatt
- skift_slut
Shift_begin-event skickas när jobbet startas för första gången. Skicka aldrig mer än en shift_begin-händelse för varje jobb!
Paused-event pausar jobbet.
Continued-event återupptar ett pausat jobb.
Shift_end avslutar jobbet. Skicka aldrig mer än en shift_end-händelse för varje jobb!
Obligatoriska uppgifter för tidsloggar:
- person_id
- Kan hittas från /people-endpoint
- Inte samma sak som user_id!
- planerad_arbetsstation_id
- Arbetsstationen där jobbet utförs
- Kan hittas från /workstations-endpoint
- datum_tid
- Tidpunkten då händelsen äger rum
- Format: 2024-01-01 10:30:11
För att ange vilken Skyplanner-tidslogg som är kopplad till tidsloggen från det externa system du använder kan du använda fältet external_id . Du kan då t.ex. göra GET-förfrågningar med detta id för att hitta en specifik tidslogg från Skyplanner.
Starta ett nytt jobb #
Du kan starta jobb genom att skicka en POST-request som denna till API:et:
När du ställer in POST-data för tidsloggarna ska du ange workshift_id som 0 och timelog_finalized som true
Pausa ett jobb #
Pausa jobb genom att skicka en POST-begäran så här:
I tidsloggar av pausad typ kan du ställa in belopp och faulty_amount. Observera även tidloggtyp och date_time.
Fortsätta ett arbete #
Så här fortsätter du en pausad tidslogg:
Observera att om du försöker fortsätta ett jobb som har avslutats av en shift_end-händelse, kommer du att få ett felmeddelande.
Avsluta en anställning #
Så här avslutar du ett jobb med en shift_end timelog:
I shift_end-events kan du ange värdena amount och faulty_amount precis som i paused-events. Observera att om du försöker göra en shift_end-event för ett jobb som inte körs kommer du att få ett felmeddelande.
Uppdatering av tidsloggar #
Du kan uppdatera tidsloggdata genom att skicka PUT-begäranden till /timelogs-endpoint, så här:
Observera att du måste ha både beginTimelog- och endTimelog-datauppsättningar för att kunna göra en uppdatering. Timelogs i Skyplanner lagras på följande sätt: varje “fullständig” (timelog som har både start och slut (t.ex. shift_begin/continued & paused/shift_end) timelog har en separat enhet för start och slut.
Dessa paras ihop med begin_id-värdet som finns i endlog. I exemplet ovan har beginTimelog id-värdet 1 och därmed har dess endTimelog begin_id-värdet 1.
Du måste också ange värdena person_id och endTimelog för varje gång du gör en uppdateringsbegäran, även om du inte ändrar dem.
Alternativa sätt att göra tidsloggar #
Här är några alternativa sätt du kan logga in på dina jobb med hjälp av API:et.
Logfull #
Om du vill skicka både början och slutet av tidsloggen i en enda begäran kan du använda /timelogs/log-full -endpoint, så här:
Observera hur beloppen skickas här: det första “amount”-värdet anger det felaktiga beloppet och det andra beloppet beloppet. Denna begäran skapar entiteterna beginlog och endlog i en enda begäran.
Quicklog #
“Quickloggning” till ett jobb slutför det i en enda begäran, ställer in den slutförda mängden produkter så att den matchar det värde som anges i orderposten. Quickloggning görs genom att använda /timelogs/quick-log -endpoint:
Observera att du här endast behöver ange produktions_planering_job_id, planerad_arbetsstation_id och person_id. Värdena för tid och belopp fylls i automatiskt. Observera också att kvickloggade jobb alltid avslutas med shift_end-händelsen, så ingen ytterligare loggning är möjlig efter kvickloggning!