Skyplanner-datastruktur #
Før vi dykker ned i tidsloggene, er vi nødt til at tale lidt om datastrukturen i Skyplanner, og hvordan tingene fungerer under motorhjelmen. Alt dette kommer i spil senere.
Hvis du har integreret dine ordre-/arbejdsordre-/jobdata i Skyplanner, har du højst sandsynligt brugt mindst disse API-endpoints:
- phaser-ordrer
- phaser-rækkefølge-rækker
- phaser-jobs
Data, der indsættes i disse endpoints, repræsenteres i Skyplanner-brugergrænsefladen på denne måde:
Når du har indsat dine ordrer i Skyplanner, skal du eksportere dem (dette kan gøres via brugergrænsefladen eller /phaser-orders/export-endpoint) til produktionsplanlægningsmodulet:
Når man eksporterer ordrer, kopierer Skyplanner effektivt ordredataene fra en databasetabel til en anden. Så hvis du f.eks. ændrer noget via /phaser-orders -endpoint, skal du eksportere dataene igen for at opdatere dem i produktionsplanlægningen. Det betyder også, at du skal bruge forskellige API-endpoints for at få adgang til de ordrer, du ser i produktionsplanlægningsvinduet!
De “ændrede” slutpunkter ser sådan ud:
- /phaser-ordrer → /ordrer
- /phaser-rækkefølge-rækker → /rækkefølge-rækker
- /phaser-jobs → /jobs
Det er vigtigt at vide, for når du bruger /timelogs -endpointet til at logge dine produktionshændelser osv., skal du bruge de relaterede enheder, der findes i Production Scheduling -endpointet!
For eksempel skal du bruge production_planning_job_id (for at gentage: production_planning_jobs er de enheder, der er adgang til fra /jobs -endpoint) for at POSTe en ny timelog:
Du kan finde det production_planning_job_id, du skal bruge, fra enten /phaser-jobs -endpoint:
Eller fra /job-slutpunktet:
Oprettelse af timelogs ved hjælp af REST-API #
Når man laver tidslogs til Skyplanner via API’en, bruger man de samme regler og systemer som i brugergrænsefladen. Så det kan være en fordel at sætte sig ind i, hvordan systemet fungerer i brugergrænsefladen, før man forsøger at bruge det via API’en.
Grundlæggende om tidslog #
Skyplanner har fire typer timelog-begivenheder:
- skift_begyndelse
- holdt pause
- fortsat
- shift_end
Shift_begin-event sendes, når jobbet startes for første gang. Send aldrig mere end én shift_begin-begivenhed for hvert job!
Paused-event sætter jobbet på pause.
Continued-event genoptager et job, der er sat på pause.
Shift_end afslutter jobbet. Send aldrig mere end én shift_end-begivenhed for hvert job!
Nødvendige data til tidslogs:
- person_id
- Kan findes fra /people-endpoint
- Ikke det samme som user_id!
- planlagt_arbejdsstation_id
- Den arbejdsstation, hvor jobbet udføres
- Kan findes fra /workstations-endpoint
- dato_tid
- Tidspunktet, hvor begivenheden er udført
- Format: 2024-01-01 10:30:11
For at specificere, hvilken Skyplanner-tidslog der er knyttet til tidsloggen fra det eksterne system, du bruger, kan du bruge feltet external_id . Du kan så f.eks. lave GET-anmodninger ved hjælp af dette id for at finde en bestemt tidslog fra Skyplanner.
At starte et job #
Du kan starte jobs ved at sende en POST-request som denne til API’en:
Når du indstiller POST-dataene for tidsloggene, skal du sætte workshift_id til 0 og timelog_finalized til true.
Sætte et job på pause #
Sæt jobs på pause ved at sende en POST-anmodning som denne:
I tidslogge af pausetypen kan du indstille beløbet og faulty_amount. Bemærk også tidslogtypen og date_time.
Fortsættelse af et job #
Sådan fortsætter du en pauset timelog:
Bemærk, at hvis du prøver at fortsætte et job, der er blevet afsluttet af en shift_end-begivenhed, får du en fejl.
At afslutte et job #
Sådan afslutter du et job med en shift_end timelog:
I shift_end-events kan du angive beløb og faulty_amount-værdier ligesom i paused-events. Bemærk, at hvis du prøver at lave en shift_end-event på et job, der ikke kører, får du en fejl.
Opdatering af timelogs #
Du kan opdatere timelog-data ved at sende PUT-forespørgsler til /timelogs-endpoint, sådan her:
Bemærk, at du skal have både beginTimelog- og endTimelog-datasæt for at kunne foretage en opdatering. Timelogs i Skyplanner gemmes på denne måde: Hver “fuld” (timelog, der har både en start og en slutning (f.eks. shift_begin/continued & paused/shift_end) timelog har en separat enhed til start og slut.
Disse er parret med begin_id-værdien , der findes i endlog. I ovenstående eksempel har beginTimelog id-værdien 1, og dermed har endTimelog begin_id-værdien 1.
Du skal også angive person_id- og endTimelog-værdierne , hver gang du laver en opdateringsanmodning, selv om du ikke ændrer dem.
Alternative måder at lave timelogs på #
Her er nogle alternative måder, du kan logge på dine jobs ved hjælp af API’en.
Logfuld #
Hvis du vil sende både start- og sluttidsloggen i en enkelt anmodning, kan du bruge /timelogs/log-full -endpoint, sådan her:
Bemærk, hvordan beløbene sendes her: Den første “amount”-værdi angiver det fejlbehæftede beløb, og den anden angiver beløbet. Denne anmodning opretter beginlog- og endlog-enhederne i en enkelt anmodning.
Quicklog #
“Quicklogging” til et job afslutter det i en enkelt anmodning og indstiller det afsluttede antal produkter til at matche den værdi, der er angivet i ordreposten. Quicklogging udføres ved at bruge /timelogs/quick-log -endpoint:
Bemærk, at du her kun behøver at angive production_planning_job_id, planned_workstation_id og person_id. Værdierne for tid og beløb udfyldes automatisk. Bemærk også, at quickloggede jobs altid afsluttes med shift_end-begivenheden, så der er ikke mulighed for yderligere logning efter quicklog!
