Podatkovna struktura Skyplannerja #
Preden se poglobimo v časovne zapise, moramo nekaj povedati o strukturi podatkov v programu Skyplanner in o tem, kako stvari delujejo pod pokrovom. Vse to bo prišlo v poštev pozneje.
Če ste podatke o naročilu/delovnem nalogu/delu vključili v program Skyplanner, ste najverjetneje uporabili vsaj te točke API:
- phaser-orders
- phaser-Order-rows
- phaser-jobs
Podatki, vstavljeni v te končne točke, so v uporabniškem vmesniku programa Skyplanner prikazani na naslednji način:
Po vnosu naročil v program Skyplanner jih boste želeli izvoziti (to lahko storite prek uporabniškega vmesnika ali končne točke /phaser-orders/export-endpoint) v modul za načrtovanje proizvodnje:
Pri izvozu naročil Skyplanner dejansko kopira podatke o naročilu iz ene tabele podatkovne zbirke v drugo. Če torej nekaj spremenite, na primer prek končne točke /phaser-orders, morate podatke ponovno izvoziti, da jih posodobite v načrtovanju proizvodnje. To tudi pomeni, da morate za dostop do naročil, ki jih vidite v oknu načrtovanja proizvodnje, uporabiti različne končne točke API!
“Spremenjene” končne točke so naslednje:
To je pomembno vedeti, ker morate pri uporabi končne točke /timelogs za beleženje proizvodnih dogodkov itd. uporabiti povezane entitete, ki jih najdete v končnih točkah za načrtovanje proizvodnje!
Za pošiljanje novega časovnega dnevnika potrebujete na primer podatek production_planning_job_id (ponovimo: production_planning_jobs so entitete, do katerih dostopate s končne točke /jobs):
Potrebni podatek production_planning_job_id lahko najdete v končni točki /phaser-jobs:
Ali iz končne točke /job:
Ustvarjanje časovnih zapisov z uporabo vmesnika REST-API #
Pri ustvarjanju časovnih zapisov v programu Skyplanner prek vmesnika API se uporabljajo ista pravila in sistemi kot v uporabniškem vmesniku. Zato je morda koristno, da se seznanite z delovanjem sistema v uporabniškem vmesniku, preden ga poskušate uporabljati prek API.
Osnove časovnega zapisa #
Skyplanner ima štiri vrste dogodkov časovnega zapisa:
- shift_begin
- prekinitev
- nadaljevanje
- shift_end
Dogodek Shift_begin se pošlje ob prvem zagonu opravila. Nikoli ne pošiljajte več kot enega dogodka shift_begin za vsako delovno mesto!
Dogodek Paused ustavi delo.
Nadaljevanje dogodka nadaljuje prekinjeno delo.
Shift_end zaključi delo. Nikoli ne pošiljajte več kot enega dogodka shift_end za vsako delo!
Zahtevani podatki za časovne zapise:
- person_id
- Najdete ga v končni točki /people
- Ni isto kot user_id!
- planned_workstation_id
- Delovno mesto, na katerem se opravlja delo
- Najdete ga v končni točki /workstations-endpoint
- datum_čas
- trenutek izvedbe dogodka
- Format: 2024-01-01 10:30:11
Če želite določiti, kateri časovni dnevnik programa Skyplanner je povezan s časovnim dnevnikom iz katerega koli zunanjega sistema, ki ga uporabljate, lahko uporabite polje external_id . S tem id lahko na primer zahtevate GET, da bi našli določen časovni dnevnik iz Skyplannerja.
Začetek dela #
Delovna mesta lahko zaženete tako, da API-ju pošljete POST-zahtevek, kot je ta:
Pri nastavljanju podatkov POST za časovne dnevnike nastavite workshift_id kot 0 in timelog_finalized kot true
Prekinitev opravila #
Delovna mesta zaustavite tako, da pošljete zahtevo POST, kot je ta:
V časovnih dnevnikih z začasno prekinitvijo lahko nastavite znesek in znesek napake. Upoštevajte tudi vrsto časovnega dnevnika in datum_čas.
Nadaljevanje dela #
Tukaj je opisano, kako nadaljujete ustavljen časovni dnevnik:
Če poskušate nadaljevati delo, ki se je končalo z dogodkom shift_end, se pojavi napaka.
Zaključek delovnega mesta #
Tukaj je prikazano, kako končate delo s časovnim zapisom shift_end:
V ukazu shift_end-events lahko podate vrednosti amount in faulty_amount enako kot v ukazu paused-events. Upoštevajte, da se pri poskusu izvedbe dogodka shift_end-event za opravilo, ki ne teče, pojavi napaka.
Posodabljanje časovnih zapisov #
Podatke časovnega dnevnika lahko posodobite tako, da na končno točko /timelogs-endpoint pošljete zahtevke PUT, kot sledi:
Upoštevajte, da morate imeti nastavljene podatke beginTimelog in endTimelog , če želite izvesti posodobitev. Časovni zapisi v programu Skyplanner so shranjeni takole: vsak “polni” (časovni zapis, ki ima začetek in konec (npr. shift_begin/continued & paused/shift_end) časovni zapis ima ločeno entiteto za začetek in konec.
Te so seznanjene z vrednostjo begin_id , ki jo najdete v dnevniku endlog. V zgornjem primeru ima beginTimelog vrednost id 1, zato ima endTimelog vrednost begin_id 1.
Vrednosti person_id in endTimelog morate navesti tudi ob vsaki zahtevi za posodobitev, tudi če jih ne spreminjate.
Alternativni načini za izdelavo časovnih zapisov #
Tukaj je nekaj alternativnih načinov prijave v delovna mesta prek vmesnika API.
Logfull #
Če želite v eni zahtevi poslati začetni in končni dnevnik, lahko uporabite /timelogs/log-full -endpoint, kot sledi:
Upoštevajte, kako so tu poslani zneski: prva vrednost “znesek” označuje napačni znesek, druga pa znesek. Ta zahteva ustvari entiteti beginlog in endlog v eni sami zahtevi.
Hitri dnevnik #
“Hitra prijava” k nalogu ga zaključi z enim samim zahtevkom in nastavi zaključeno količino izdelkov tako, da se ujema z vrednostjo, nastavljeno v elementu naročila. Hitro beleženje se izvede z uporabo končne točke /timelogs/quick-log:
Upoštevajte, da morate tukaj navesti samo podatke production_planning_job_id, planned_workstation_id in person_id. Vrednosti časa in zneska se izpolnijo samodejno. Upoštevajte tudi, da se hitro prijavljena delovna mesta vedno zaključijo z dogodkom shift_end-event, zato po quicklogu nadaljnje prijavljanje ni mogoče!