Skyplanner datu struktūra #
Pirms pievērsīsimies laika grafikiem, mums nedaudz jāapspriež Skyplanner datu struktūra un tas, kā viss darbojas zem pārsega. Tas viss tiks aplūkots vēlāk.
Ja esat integrējis savu pasūtījumu/darba uzdevumu/darbu datus programmā Skyplanner, visticamāk, izmantojāt vismaz šos API punktus:
- phaser-orders
- phaser-order-rows
- phaser-jobs
Faktiski šajos galapunktos ievietotie dati Skyplanner lietotāja saskarnē tiek attēloti šādi:
Pēc pasūtījumu ievietošanas programmā Skyplanner tos eksportēsiet (to var izdarīt, izmantojot lietotāja saskarni vai /phaser-orders/export-endpoint) uz ražošanas plānošanas moduli:
Eksportējot pasūtījumus, Skyplanner faktiski kopē pasūtījumu datus no vienas datu bāzes tabulas uz citu. Tāpēc, ja kaut ko maināt, piemēram, izmantojot /phaser-orders -endpoint, dati ir jāeksportē vēlreiz, lai tos atjauninātu ražošanas plānošanas programmā. Tas arī nozīmē, ka, lai piekļūtu pasūtījumiem, kas redzami ražošanas plānošanas logā, ir jāizmanto dažādi API galapunkti!
“Izmainītie” galapunkti ir šādi:
- /phaser-orders → /orders
- /phaser-order-rows → /order-rows
- /phaser-jobs → /jobs
To ir svarīgi zināt, jo, izmantojot /timelogs -endpoint, lai reģistrētu savus ražošanas notikumus u.c., jums ir jāizmanto saistītās vienības, kas atrodamas Production Scheduling -endpoint!
Piemēram, jums ir nepieciešams production_planning_job_id (atkārtojam: production_planning_jobs ir vienības, kurām piekļūst no /jobs -endpoint), lai POSTinātu jaunu laika grafiku:
Jums vajadzīgo production_planning_job_id varat atrast no /phaser-jobs -endpoint:
Vai no /job -endpoint:
Laika grafiku izveide, izmantojot REST-API #
Laika grafiku veidošana programmā Skyplanner, izmantojot API, izmanto tos pašus noteikumus un sistēmas, kas ir lietotāja saskarnē. Tāpēc varētu būt lietderīgi iepazīties ar to, kā sistēma darbojas lietotāja saskarnē, pirms mēģināt to izmantot, izmantojot API.
Laika grafika pamati #
Skyplanner ir četri laika grafika notikumu veidi:
- shift_begin
- apturēta
- turpinājums
- shift_end
Shift_begin-event tiek nosūtīts, kad darbs tiek sākts pirmo reizi. Katram darbam nekad nesūtiet vairāk par vienu notikumu shift_begin!
Paused-event aptur darbu.
Turpināts notikums atsāk apturētu darbu.
Shift_end pabeidz darbu. Nekad nesūtiet vairāk par vienu shift_end notikumu katram darbam!
Nepieciešamie dati laika grafikiem:
- person_id
- Var atrast no /people-endpoint
- Nav tas pats, kas user_id!
- planned_workstation_id
- Darba vieta, kurā tiek veikts darbs
- Var atrast no /workstations-endpoint
- date_time
- Notikuma izpildes laiks
- Formāts: 2024-01-01 10:30:11
Lai norādītu, kāds Skyplanner laika žurnāls ir piesaistīts laika žurnālam no jebkuras jūsu izmantotās ārējās sistēmas, varat izmantot lauku external_id . Pēc tam varat, piemēram, veikt GET pieprasījumus, izmantojot šo id, lai atrastu konkrētu laika žurnālu no Skyplanner.
Darba sākšana #
Darba uzdevumus var sākt, nosūtot API šādu POST pieprasījumu:
Iestatot POST datus laika grafikiem, iestatiet workshift_id kā 0 un timelog_finalized kā true.
Darba apturēšana #
Pārtrauciet darbu, nosūtot šādu POST pieprasījumu:
Pauzes tipa taimelogos var iestatīt summu un faulty_amount. Ņemiet vērā arī laikrāmatu žurnāla tipu un date_time.
Darba turpināšana #
Tālāk aprakstīts, kā turpināt apturētu laika žurnālu:
Ņemiet vērā, ka, ja mēģināsiet turpināt darbu, kas ir pabeigts ar notikumu shift_end, tiks pieļauta kļūda.
Darba attiecību izbeigšana #
Lūk, kā jūs pabeidzat darbu ar maiņas_galapunkta laika grafiku:
Shift_end-events var norādīt summu un faulty_amount vērtības tāpat kā paused-events. Ņemiet vērā, ka, ja mēģināsiet veikt shift_end-event darbam, kas netiek izpildīts, tiks parādīta kļūda.
Laika grafiku atjaunināšana #
Laika žurnāla datus var atjaunināt, nosūtot PUT pieprasījumus uz /timelogs-endpoint, piemēram, šādi:
Ņemiet vērā, ka, lai veiktu atjaunināšanu, ir jābūt iestatītiem gan beginTimelog , gan endTimelog datiem. Skyplanner laika žurnāli tiek glabāti šādi: katram “pilnajam” (laika žurnālam, kam ir gan sākums, gan beigas (piemēram, shift_begin/continued & paused/shift_end) laika žurnālam ir atsevišķa sākuma un beigu vienība.
Tie tiek savienoti pārī ar begin_id vērtību, kas atrodama endlog. Iepriekš minētajā piemērā beginTimelog ir id vērtība 1, un tādējādi tā endTimelog ir begin_id vērtība 1.
Jums ir jānorāda arī person_id un endTimelog vērtības katru reizi, kad veicat atjaunināšanas pieprasījumu, pat ja tās nemaināt.
Alternatīvi veidi, kā veikt laika grafikus #
Šeit ir daži alternatīvi veidi, kā varat pieteikties darbvietām, izmantojot API.
Logfull #
Ja vēlaties vienā pieprasījumā nosūtīt gan sākuma, gan beigu laikrādi, varat izmantot /timelogs/log-full -endpoint, piemēram, šādi:
Ņemiet vērā, kā šeit tiek nosūtītas summas: pirmā vērtība “summa” apzīmē kļūdaino summu, bet otrā – summu. Šis pieprasījums izveido beginlog un endlog vienības vienā pieprasījumā.
Ātrais žurnāls #
“Ātrā pieteikšanās” uzdevumam pabeidz to ar vienu pieprasījumu, nosaka pabeigto produktu daudzumu, lai tas atbilstu pasūtījuma vienībā iestatītajai vērtībai. Ātrā reģistrēšana tiek veikta, izmantojot /timelogs/quick-log -endpoint:
Ņemiet vērā, ka šeit ir jānorāda tikai production_planning_job_id, planned_workstation_id un person_id. Laika un summas vērtības tiek aizpildītas automātiski. Ņemiet vērā arī to, ka ātri reģistrētie darbi vienmēr tiek pabeigti ar notikumu shift_end-event, tāpēc pēc quicklog turpmāka reģistrēšana nav iespējama!