Skyplanner gegevensstructuur #
Voordat we in de timelogs duiken, moeten we eerst iets vertellen over de gegevensstructuur in Skyplanner en hoe alles onder de motorkap werkt. Dit zal later allemaal aan bod komen.
Als je je Order-/werkorder-/jobgegevens in Skyplanner hebt geïntegreerd, heb je waarschijnlijk ten minste deze API-endpoints gebruikt:
- faser-bestellingen
- faser-Order-rows
- faser-jobs
Gegevens die in deze eindpunten worden ingevoerd, worden als volgt weergegeven in de Skyplanner UI:
Na het invoegen van je orders in Skyplanner wil je ze exporteren (dit kan via de UI of het /phaser-orders/export-endpoint) naar de module Productieplanning:
Bij het exporteren van orders kopieert Skyplanner de ordergegevens van de ene databasetabel naar de andere. Dus als je iets wijzigt via bijvoorbeeld het /phaser-orders -endpoint, moet je de gegevens opnieuw exporteren om ze bij te werken in Productieplanning. Dit betekent ook dat je verschillende API-endpoints moet gebruiken om toegang te krijgen tot de orders die je ziet in het venster Productieplanning!
De “gewijzigde” eindpunten gaan als volgt:
Dit is belangrijk om te weten, want als je het /timelogs -endpoint gebruikt om je productiegebeurtenissen etc. te loggen , moet je de gerelateerde entiteiten gebruiken die je vindt in Production Scheduling -endpoints!
Je hebt bijvoorbeeld de production_planning_job_id nodig (om te herhalen: production_planning_jobs zijn de entiteiten die worden benaderd vanaf het /jobs -endpoint) om een nieuw timelog te POST’en:
Je kunt de production_planning_job_id die je nodig hebt vinden via het /phaser-jobs -endpoint:
Of vanaf het /job -eindpunt:
Tijdlogs maken met de REST-API #
Het maken van tijdschema’s naar Skyplanner via de API maakt gebruik van dezelfde regels en systemen als in de UI. Het kan dus nuttig zijn om jezelf vertrouwd te maken met hoe het systeem werkt in de UI voordat je het probeert te gebruiken via de API.
Basisprincipes tijdlog #
Skyplanner heeft vier soorten tijdloggebeurtenissen:
- shift_begin
- gepauzeerd
- vervolg
- shift_einde
Shift_begin-event wordt verzonden wanneer de taak voor de eerste keer wordt gestart. Stuur nooit meer dan één shift_begin-event voor elke taak!
Met Paused-event wordt de taak gepauzeerd.
Continued-event hervat een gepauzeerde taak.
Shift_end voltooit de taak. Stuur nooit meer dan één shift_end gebeurtenis voor elke taak!
Vereiste gegevens voor timelogs:
- persoon_id
- Kan worden gevonden via het /people-endpoint
- Niet hetzelfde als user_id!
- gepland_werkstation_id
- De werkplek waar de taak wordt uitgevoerd
- Kan worden gevonden vanaf het /workstations-eindpunt
- datum_tijd
- Het tijdstip waarop de gebeurtenis plaatsvindt
- Formaat: 2024-01-01 10:30:11
Om te specificeren welke Skyplanner timelog gekoppeld is aan de timelog van welk extern systeem je ook gebruikt, kun je het external_id veld gebruiken. Je kunt dan bijvoorbeeld GET-verzoeken doen met dit id om een specifiek timelog van Skyplanner te vinden.
Een baan beginnen #
Je kunt taken starten door een POST-verzoek als dit naar de API te sturen:
Stel bij het instellen van de POST-gegevens voor de timelogs workshift_id in op 0 en timelog_finalized op true.
Een taak onderbreken #
Taken pauzeren door een POST-verzoek als dit te verzenden:
In timelogs van het gepauzeerde type kun je het bedrag en fout_bedrag instellen. Let ook op het timelogtype en de date_time.
Een baan voortzetten #
Zo ga je verder met een gepauzeerd timelog:
Merk op dat als je een taak probeert voort te zetten die is beëindigd door een shift_end gebeurtenis, je een foutmelding krijgt.
Een baan beëindigen #
Hier zie je hoe je een taak beëindigt met een shift_end timelog:
In shift_end-events kun je de waarden amount en faulty_amount opgeven, net als in paused-events. Merk op dat als je een shift_end-event probeert uit te voeren op een taak die niet actief is, je een foutmelding krijgt.
Tijdlogs bijwerken #
Je kunt timeloggegevens bijwerken door PUT-verzoeken te sturen naar het /timelogs-endpoint, zoals dit:
Merk op dat je zowel de beginTimelog als de eindTimelog gegevens moet hebben om een update te kunnen doen. Timelogs in Skyplanner worden als volgt opgeslagen: elke “volledige” (timelog die zowel een begin als einde heeft (bijv. shift_begin/continued & paused/shift_end) timelog heeft een aparte entiteit voor het begin en einde.
Deze worden gekoppeld door de begin_id waarde die gevonden wordt in het eindlog. In het bovenstaande voorbeeld heeft het beginTimelog de id-waarde 1 en dus heeft het eindTimelog de begin_id waarde 1.
Je moet ook de person_id en endTimelog waarden opgeven voor elke keer dat je een updateverzoek doet, zelfs als je ze niet wijzigt.
Alternatieve manieren om tijdlogs te maken #
Hier zijn enkele alternatieve manieren waarop je je kunt aanmelden bij je taken met behulp van de API.
Logfull #
Als je zowel de begin- als eindtijdlogs in een enkel verzoek wilt verzenden, kun je het /timelogs/log-full -endpoint gebruiken, zoals dit:
Merk op hoe de bedragen hier worden verzonden: de eerste “amount” waarde duidt het foutieve bedrag aan en de tweede het bedrag. Dit verzoek creëert de entiteiten beginlog en endlog in één enkel verzoek.
Snellog #
“Quicklogging” naar een taak voltooit deze in een enkele aanvraag en stelt het voltooide aantal producten in op de waarde die is ingesteld in het bestelitem. Quicklogging wordt gedaan met behulp van het /timelogs/quick-log -endpoint:
Merk op dat je hier alleen de production_planning_job_id, planned_workstation_id en person_id hoeft op te geven. De waarden voor tijd en bedrag worden automatisch ingevuld. Merk ook op dat quicklogged jobs altijd worden voltooid met de shift_end-event, dus er is geen verdere logging mogelijk na quicklog!