Skyplanner-datastruktur #
Før vi går nærmere inn på tidsloggene, må vi snakke litt om datastrukturen i Skyplanner og hvordan ting fungerer under panseret. Alt dette kommer vi tilbake til senere.
Hvis du har integrert ordre-/arbeidsordre-/jobbdata i Skyplanner, har du sannsynligvis brukt minst disse API-endepunktene:
- phaser-ordrer
- phaser-Order-rader
- phaser-jobs
Data som legges inn i disse endepunktene, vises på denne måten i Skyplanner-brukergrensesnittet:
Etter at du har lagt inn ordrene dine i Skyplanner, vil du eksportere dem (dette kan gjøres via brukergrensesnittet eller /phaser-orders/export-endpoint) til produksjonsplanleggingsmodulen:
Når du eksporterer bestillinger, kopierer Skyplanner i praksis bestillingsdataene fra én databasetabell til en annen. Så hvis du for eksempel endrer noe gjennom /phaser-orders -endepunktet, må du eksportere dataene på nytt for å oppdatere dem i Produksjonsplanlegging. Dette betyr også at du må bruke forskjellige API-endepunkter for å få tilgang til ordrene du ser i produksjonsplanleggingsvinduet!
De “endrede” endepunktene ser slik ut:
Dette er viktig å vite, for når du bruker /timelogs -endepunktet til å logge produksjonshendelser osv., må du bruke de relaterte entitetene som finnes i Production Scheduling -endepunktene!
Du trenger for eksempel production_planning_job_id (for å gjenta: production_planning_jobs er entitetene du får tilgang til fra /jobs -endepunktet) for å legge inn en ny timelogg:
Du finner production_planning_job_id du trenger fra enten /phaser-jobs -endepunktet:
Eller fra /job-sluttpunktet:
Opprette tidslogger ved hjelp av REST-API #
Når du lager tidslogger til Skyplanner via API-et, brukes de samme reglene og systemene som i brukergrensesnittet. Det kan derfor være en fordel å sette seg inn i hvordan systemet fungerer i brukergrensesnittet før du prøver å bruke det via API-et.
Grunnleggende om tidslogg #
Skyplanner har fire typer tidslogghendelser:
- shift_begin
- satt på pause
- fortsatt
- shift_end
Shift_begin-event sendes når jobben startes for første gang. Send aldri mer enn én shift_begin-hendelse for hver jobb!
Paused-hendelsen setter jobben på pause.
Continued-event gjenopptar en jobb som er satt på pause.
Shift_end fullfører jobben. Send aldri mer enn én shift_end-hendelse for hver jobb!
Nødvendige data for tidslogger:
- person_id
- Finnes fra /people-sluttpunktet
- Ikke det samme som user_id!
- planned_workstation_id
- Arbeidsstasjonen der jobben utføres
- Finnes fra /workstations-endpoint
- dato_tid
- Tidspunktet for når hendelsen er utført
- Format: 2024-01-01 10:30:11
For å spesifisere hvilken Skyplanner-tidslogg som er knyttet til tidsloggen fra det eksterne systemet du bruker, kan du bruke feltet external_id . Du kan da for eksempel gjøre GET-forespørsler ved hjelp av denne id-en for å finne en spesifikk tidslogg fra Skyplanner.
Å begynne i jobb #
Du kan starte jobber ved å sende en POST-forespørsel som dette til API-et:
Når du setter POST-dataene for tidsloggene, setter du workshift_id til 0 og timelog_finalized til true
Sette en jobb på pause #
Sett jobber på pause ved å sende en POST-forespørsel på denne måten:
I tidslogger av typen pauset kan du angi beløp og faulty_amount. Legg også merke til tidsloggtypen og date_time.
Fortsette i jobb #
Slik fortsetter du en tidslogg som er satt på pause:
Merk at hvis du prøver å fortsette en jobb som har blitt avsluttet av en shift_end-hendelse, vil du få en feilmelding.
Å avslutte en jobb #
Slik avslutter du en jobb med en shift_end timelog:
I shift_end-events kan du oppgi beløp og faulty_amount-verdier på samme måte som i paused-events. Merk at hvis du prøver å utføre en shift_end-hendelse på en jobb som ikke kjører, vil du få en feilmelding.
Oppdatering av tidslogger #
Du kan oppdatere tidsloggdata ved å sende PUT-forespørsler til /timelogs-endepunktet, slik som dette:
Merk at du må ha både beginTimelog- og endTimelog-data angitt for å kunne gjøre en oppdatering. Tidslogger i Skyplanner lagres på denne måten: Hver “full” (tidslogg som har både start og slutt (f.eks. skift_begin/fortsatt og paused/skift_slutt)) tidslogg har en egen enhet for start og slutt.
Disse er paret med begin_id-verdien som finnes i endlog. I eksempelet ovenfor har beginTimelog id-verdien 1, og dermed har endTimelog begin_id-verdien 1.
Du må også oppgi person_id- og endTimelog-verdiene for hver gang du gjør en oppdateringsforespørsel, selv om du ikke endrer dem.
Alternative måter å lage tidslogger på #
Her er noen alternative måter du kan logge på jobbene dine ved hjelp av API-et.
Logfull #
Hvis du vil sende både start- og sluttidsloggen i én enkelt forespørsel, kan du bruke /timelogs/log-full -endpoint, slik:
Legg merke til hvordan beløpene sendes her: Den første “amount”-verdien angir feilbeløpet og den andre beløpet. Denne forespørselen oppretter entitetene beginlog og endlog i én og samme forespørsel.
Quicklog #
“Quicklogging” til en jobb fullfører den i én enkelt forespørsel, og setter det fullførte antallet produkter til å samsvare med verdien som er angitt i bestillingselementet. Quicklogging gjøres ved å bruke /timelogs/quick-log -endepunktet:
Merk at du her bare trenger å oppgi production_planning_job_id, planned_workstation_id og person_id. Verdiene for tid og beløp fylles ut automatisk. Vær også oppmerksom på at quickloggede jobber alltid avsluttes med shift_end-hendelsen, så det er ikke mulig å logge videre etter quicklog!
