Zināšanu bāze Integrācija

Kas ir notikumu sūtītājs? Funkcionalitāte, kas automātiski nosūta informāciju par izmaiņām uz ārējām sistēmām, izmantojot webhook mehānismu. Tas ļauj integrēt Horizon ar citām sistēmām reāllaikā, automātiski nosūtot datus par notikumiem, piemēram, lietotāju izmaiņām vai nomenklatūru atlikumiem. Horizon ceļš: Sistēma -> Datu apmaiņa -> Notikumu sūtītājs     Lai aktivizētu notikumu sūtītāju ir jāizpilda sekojoši soļi: 1. Atveriet izvēlni Sistēma → Datu apmaiņa → Notikumu sūtītājs → Notikumu sūtītāja metodes un nospiediet pogu Jauns. 2. Pamatinformācijas aizpildīšana Aizpildiet galvenos obligātos laukus: • Kods: Ievadiet unikālu identifikatoru,  • Nosaukums: Ievadiet metodei saprotamu nosaukumu • Notikuma veids: Izvēlieties vajadzīgo tipu, piemēram, "WEB lietotāji" vai "Nomenklatūru brīvie atlikumi". Svarīgi! Ja izvēlaties Nomenklatūru brīvos atlikumus, sadaļā "Konfigurācija" obligāti  jāizvēlas esošs vai jāizveido jauns datu filtrs. 3. Metodes aktivizēšana un adreses norādīšana • Statuss: Lai metodi aktivizētu, izvēlieties statusu Aktīvs. • Endpoint: Ievadiet ārējās sistēmas URL adresi, uz kuru sūtīt datus (adresei obligāti jāsākas ar https://). 4. Autentifikācija un sūtīšanas laiki • Autentifikācija: Izvēlieties Bez auth (ja ārējā adrese ir publiska) vai Basic auth (ievadot lietotājvārdu un paroli). • Periodiskums: Varat atstāt noklusētos iestatījumus, kas sūtīs datus ik pēc 5 minūtēm darba laikā no 06:00 līdz 21:00, vai arī pielāgot tos savām vajadzībām.   Lai strādātu ar notikumu sūtītāju, nepieciešamas tiesības: Sistēma → Datu apmaiņa → Notikumu sūtītāja metodes → Apskatīt Sistēma → Datu apmaiņa → Notikumu sūtītāja metodes → Labot Notikumu sūtītājs būs pieejams visiem, kam ir Integrāciju paka.   Kā strādā notikumu sūtītājs? • Notikumu reģistrēšana: Kad Horizon sistēmā notiek piesaistītās izmaiņas (piemēram, saglabājot saņemšanas dokumentu vai ievadot kases dokumentu, mainās nomenklatūru atlikumi), sistēma fiksē šo notikumu datubāzē ar statusu "Jauns". Ja metodei ir iestatīta konfigurācija jeb filtri, sistēma pirms tam pārbauda, vai notikums atbilst noteiktajiem kritērijiem. • Datu formēšana: Reģistrētie notikumi tiek apkopoti un pārvērsti JSON formātā. Lai optimizētu datu pārraidi, vairāki atsevišķi notikumi pirms sūtīšanas tiek apvienoti vienā datu pakā. • Nosūtīšanas process (Serviss): Fona serviss seko līdzi iestatītajam periodiskumam (piemēram, ik pēc 5 minūtēm atļautajā laika intervālā) un ģenerē HTTP POST pieprasījumus uz ārējās sistēmas adresi (Endpoint). Ja konfigurācijā ir norādīta Basic auth autentifikācija, serviss automātiski pievieno autentifikācijas galveni HTTP pieprasījumam. • Atbildes apstrāde un atkārtošana: Lai sūtījums tiktu uzskatīts par veiksmīgu, ārējai sistēmai ir jāatgriež HTTP statusa kods 200-299. Ja saziņa neizdodas tīkla vai ārējās sistēmas kļūdas dēļ, Horizon serviss piešķir ierakstam statusu "Tiks sūtīts atkārtoti" (īslaicīga aizture pirms atkārtota mēģinājuma) vai "Neizdevās nosūtīt" (atkārtos nākamajā plānotajā ciklā). Ja tiek sasniegts maksimālais atļautais neveiksmīgo mēģinājumu skaits, metode tiek automātiski deaktivizēta aizsardzības nolūkos. • Automātiskā uzturēšana: Lai sistēma nepārpildītos ar veciem žurnālu datiem, katru dienu ārpus darba laika automātiski tiek dzēsti veiksmīgi nosūtītie ieraksti un dublikāti (vecāki par 10 dienām), kā arī kļūdainie ieraksti (vecāki par 30 dienām).   Kā atsekot sūtāmajiem notikumiem? Horizon Notikumu sūtītāja funkcionalitāte ietver divus žurnālu sarakstus, kas nepieciešami datu nosūtīšanas procesa uzraudzībai, pārbaudei un kļūdu (piemēram, nepiegādātu datu vai nepieejamas ārējās adreses) identificēšanai. 1. Notikumu sūtītāja ierakstu žurnāls: Parāda visus atsevišķos notikumus, kas reģistrēti sistēmā. Tas ir nepieciešams, lai detalizēti izsekotu katra konkrētā notikuma stāvoklim, redzētu tā reģistrēšanas datumu un metodi, kas atbild par šī notikuma apstrādi. 2. Notikumu sūtītāja paku žurnāls: Parāda nosūtītās notikumu pakas, jo bieži vien vairāki notikumi tiek apvienoti vienā pakā. Šis žurnāls ir noderīgs, lai pārraudzīt kopējo uz ārējās sistēmas adresi (endpoint URL) nosūtīto datu plūsmu un pakas piegādes gaitu.   Sistēmas žurnālos ierakstiem var būt dažādi statusi, kas atspoguļo to apstrādes fāzi (paku žurnālā statusi ir analogi atsevišķu ierakstu statusiem): • Jauns: Notikums ir reģistrēts, taču serviss vēl nav mēģinājis to nosūtīt. Ja saņēmēja adrese ir aktīva, piegāde notiks nākamajā plānotajā sūtīšanas reizē. • Tiks sūtīts atkārtoti: Īslaicīgs statuss, ko izmanto īslaicīgu problēmu, piemēram, tīkla pārtraukumu, risināšanai. Tas nozīmē, ka sūtīšana tikko neizdevās, bet serviss ar nelielu aizturi tūlīt veiks atkārtotu mēģinājumu. • Neizdevās nosūtīt: Sūtīšanas mēģinājums nav izdevies, bet serviss turpinās mēģināt datus piegādāt nākamajā plānotajā izpildes reizē. Sistēma šādus ierakstus un pakas automātiski dzēš pēc 30 dienām. • Nosūtīts: Gala statuss, kas nozīmē, ka notikums vai paka ir veiksmīgi nosūtīta uz norādīto endpoint adresi. Šie ieraksti automātiski tiek dzēsti pēc 10 dienām. • Dublikāts: Gala statuss, kas norāda, ka notikums netiks sūtīts, jo tā dati sakrīt ar citu jau esošu notikumu. Arī šos ierakstus sistēma izdzēsīs pēc 10 dienām.   Ja notikumi netiek sūtīti, ieteicams veikt šādas pārbaudes, lai identificētu un novērstu problēmu: • Pārbaudiet metodes statusu: Sistēmā metodei obligāti jābūt ar statusu "Aktīvs". Ja tas ir iestatīts kā "Tikai datu vākšana", notikumi tiek uzkrāti žurnālā, bet netiek sūtīti uz ārējo sistēmu. Jāņem vērā, ka metode var tikt automātiski deaktivizēta, ja ir sasniegts maksimālais neveiksmīgo sūtīšanas mēģinājumu skaits (piemēram, ilgstošu ārējās sistēmas traucējumu dēļ). Tādā gadījumā pēc problēmas atrisināšanas statuss manuāli jānomaina atpakaļ uz "Aktīvs". Ja nepieciešams caur REST API noskaidrot vai metode ir aktīva, tad ir jāizmanto TdmEventSenderMethodsBL klase. Rest pieprasījums, lai izsauktu visas metodes:  /rest/TdmEventSenderMethodsSL/query?columns=EVSENDMETH.KODS&EVSENDMETH.NOSAUK&filter=EVSENDMETH.STATUS eq '0' Rest pieprasījums, lai pārbaudītu konkrētu metodi: /rest/TdmEventSenderMethodsSL/query?columns=EVSENDMETH.KODS,EVSENDMETH.NOSAUK,EVSENDMETH.STATUS&filter=EVSENDMETH.PK_EVENTSENDERMETHODS eq '{Metodes PK}'   {Metodes PK} ir  metodes ID. • Pārbaudiet sūtīšanas laika intervālu un nedēļas dienas: Pārliecinieties, vai attiecīgā nedēļas diena ir atzīmēta un vai pašreizējais laiks ietilpst atļautajā sūtīšanas laika intervālā. Ja laiks ietilpst ārpus atļautā intervāla, notikumi turpina uzkrāties, bet tiks nosūtīti tikai nākamajā sūtīšanas logā. • Pārbaudiet notikumu žurnālus: Ieskatieties ierakstu žurnālā un pievērsiet uzmanību statusiem, kas var norādīt uz kļūdām, piemēram, "Neizdevās nosūtīt" vai "Tiks sūtīts atkārtoti". • Pārbaudiet saņēmēja adresi (endpoint): Pārliecinieties, ka URL adrese ir ievadīta pareizi, ietver https:// un ārējā sistēma ir reāli pieejama. • Pārbaudiet autentifikācijas datus: Ja metodei izmantojat Basic auth, vēlreiz pārliecinieties, vai ievadītais lietotājvārds un parole sakrīt ar ārējās sistēmas prasībām.   Kā testēt notikumu sūtīšanu?   1. Izveidojiet testa endpoint adresi: Atveriet vietni https://webhook.site (vai citu līdzīgu servisu), kas uzģenerēs unikālu testa URL adresi un ļaus pārlūkprogrammā reāllaikā redzēt visus saņemtos datus. 2. Iestatiet drošu statusu Horizon: Metodes iestatījumos norādiet iegūto testa URL adresi un izvēlieties statusu "Tikai datu vākšana". Šis statuss ļauj sistēmai reģistrēt notikumus, taču tie netiks uzreiz nosūtīti un pagaidām neparādīsies ierakstu žurnālā. 3. Izveidojiet testa notikumus: Veiciet Horizon sistēmā darbības, kurām vajadzētu izsaukt datu sūtīšanu, piemēram, pievienojiet jaunu WEB lietotāju vai izmainiet nomenklatūras atlikumu. 4. Aktivizējiet sūtīšanu: Nomainiet metodes statusu uz "Aktīvs". Pēc šīs darbības iepriekš savāktie testa notikumi parādīsies ierakstu žurnālā un tiks nosūtīti uz jūsu testa adresi. 5. Pārbaudiet rezultātu: Atgriezieties webhook.site lapā un pārliecinieties, vai dati ir veiksmīgi saņemti.   Kā var deaktivizēt sūtīšanas metodi?   • Automātiska deaktivizācija: Sistēma automātiski deaktivizēs metodi, ja tiks sasniegts maksimālais atļautais neveiksmīgo datu sūtīšanas mēģinājumu skaits. Tas kalpo kā aizsargmehānisms un parasti norāda uz ilgstošām problēmām ar ārējās sistēmas (endpoint) pieejamību vai nepareizu konfigurāciju. Šādā gadījumā ir jāatrod un jāizlabo problēmas cēlonis (piemēram, jāsalabo endpoint adrese vai autentifikācija) un pēc tam metodes statuss manuāli jānomaina atpakaļ uz "Aktīvs", lai sistēma atsāktu datu sūtīšanu. • Manuāla deaktivizācija: Lietotājs var jebkurā brīdī metodi atslēgt pats, metodes kartītē izvēloties statusu "Neaktīvs". Šajā statusā jauni notikumi netiek ne vākti, ne nosūtīti uz ārējo adresi.  

Uzņēmumiem, kur, piemēram jaunu darbinieku dati tiek piefiksēti ārpus Horizon un nepieciešams, izmantojot esošos datus, izveidot jaunus WEB lietotājus, ir pieejams REST resurss:  /rest/TdmUsersOBL Piemērs jauna WEB lietotāja izveidei (POST): ___________________________________________________________________________________________________________ <resource>     <entity>         <PAMV_ID>15125</PAMV_ID>         <ACTIVE>1</ACTIVE>         <LOGIN>JANIS_WEB</LOGIN>         <PK_USER>             <href>/rest/TdmUsrView/808</href>         </PK_USER>         <PK_USERSOGRP>             <href>/rest/TdmWebUserGroupBL/1</href>         </PK_USERSOGRP>         <VARDS>Janis</VARDS>         <UZVARDS>Janitis</UZVARDS>         <PERS_KODS>111177-11111</PERS_KODS>         <LOGIN_TYPE>0</LOGIN_TYPE>         <PAROLE_INP>robots</PAROLE_INP>         <USER_TYPE>0</USER_TYPE>         <dmUsersoFirmaRBL>             <row>                 <PK_FIRMA>56</PK_FIRMA>                 <IS_DEFAULT>1</IS_DEFAULT>                 <DATE_FROM>2025-06-03</DATE_FROM>                 <DATE_TO>3000-01-01</DATE_TO>             </row>             <dmUsersoObjRBL>                 <row>                     <PK_OBJ>1</PK_OBJ>                     <F_NOSAUK>Lanas Firma</F_NOSAUK>                     <PK_ACTTYPE>5</PK_ACTTYPE>                     <PK_FIRMA>56</PK_FIRMA>                 </row>             </dmUsersoObjRBL>         </dmUsersoFirmaRBL>         <dmUsersoInterfacesRBL/>         <dmUsersOPubAtskRBL/>     </entity> </resource> ____________________________________________________________________________________________________ Piemēra rezultāts:  Sistēma -> Administrēt -> WEB lietotāji tiek izveidota lietotāja kartīte:   <LOGIN_TYPE> - autentifikācijas veids (0- Parole; 1 - Domēna vārds; 4 - Domēna vārds vai Parole; 6 - Ārēja autentifikācija) <USER_TYPE> - konta veids (0 - Lietotāja; 1 - Sistēmkonts; 2 - Administratora; 3 - Ārējais) Svarīga informācija: Lai veidotu WEB lietotājus izmantojot REST API, integrācijā izmantotajam WEB lietotājam konta veidam ir jābūt  "Sistēmkonts" vai "Administratora konts" un WEB lietotājam piesaistītajam Horizon lietotājam ir jābūt atļautiem tiesību punktiem (Sistēma → Administrēt → Lomas) Sistēma -> Administrēt -> WEB lietotāji Apskatīt Pievienot Labot Web lietotāju veidošana, labošana, dzēšana ar Rest Horizon sarakstā: Sistēma -> Administrēt -> WEB lietotāji pieejama  kolonna "Reģistrācijas tips". Gadījumos, kad WEB lietotājs izveidots izmantojot REST API, saraksta lauka "Reģistrācijas tips" vērtība tiks aizpildīta ar "Izveidots no Rest"

Uzņēmumiem, kur, piemēram jaunu darbinieku dati tiek piefiksēti ārpus Horizon un nepieciešams, izmantojot esošos datus, izveidot jaunus Horizon lietotājus ir pieejams REST resurss:  /rest/TUser Piemērs jauna Horizon lietotāja izveidei (POST): ___________________________________________________________________________________________________________ <resource>         <entity>         <VARDST>KASPARS</VARDST>         <UZVARDST>JAUNIŅAIS</UZVARDST>        <USRPWD>1:18718:yU8jKxfAdU+p/9+BqSpUKg==:3MDR7MRnLwrMdPMo0yVq2+Wd4V1VgZtWzanQxnty3A==</USRPWD>         <PIEZIMEST>Piezīmes par lietotāju</PIEZIMEST>         <APSKATE>0</APSKATE>         <LOGIN_TYPE>0</LOGIN_TYPE>         <LOGINT>KASPARS_JAUN</LOGINT>         <USER_TYPE>0</USER_TYPE>         <AD_PWDNOEXP>1</AD_PWDNOEXP>         <dmRTUserLLFBL>             <row>                 <PK_FIRMA>56</PK_FIRMA>                 <PK_LOMA>1</PK_LOMA>             </row>         </dmRTUserLLFBL>     </entity> </resource> ___________________________________________________________________________________________________________ Piemēra rezultātā:  Sistēma -> Administrēt -> Lietotāji tiek izveidota lietotāja kartīte: <APSKATE> - licences veids: 0 - Pilna; 1 - Tikai apskate <LOGIN_TYPE> - autentifikācijas veids: 0 - Parole; 1 - Domēna v.; 3 - Domēna v. +AD parole; 2 - el.paraksts; 5 - OIDC <USER_TYPE> - konta veids: 0 - Lietotāja; 1 - Sistēmas; 2 - Administratora <AD_PWDNOEXP> - pazīme, parole nekad nenoveco: 0 - neatzīmēts; 1 - atzīmēts Svarīga informācija: Lai veidotu Horizon lietotājus izmantojot REST API, integrācijā izmantotajam WEB lietotājam konta veidam ir jābūt  "Sistēmkonts" vai "Administratora konts" un WEB lietotājam piesaistītajam Horizon lietotājam ir jābūt atļautiem tiesību punktiem (Sistēma → Administrēt → Lomas) Sistēma -> Administrēt -> Lietotāji Apskatīt Pievienot Labot Horizon lietotāju veidošana un labošana ar Rest

Integrācijām ar Horizon tiek izmantoti WEB lietotāji. Tas ir lietotāja paveids Horizon, ko izmanto pieslēgšanai WEB aplikācijām, t.sk. REST integrācijām. Veidojot WEB lietotāju, tam obligāti jānorāda Horizon lietotājs, jo pēc šī Horizon lietotāja tiek noteikta WEB lietotāja loma un tiesības, kas nosaka pieejamās funkcionālās sadaļas un tiesības apstrādāt vai skatīt datus.   Tātad vispirms nepieciešams izveidot lomu ar atbilstošām pieejas tiesībām. Vairāk par lomu veidošanu lasīt šeit. Sistēma - Administrēt - Lomas       Nākamais solis ir izveidot Horizon lietotāju. Sistēma - Administrēt - Lietotāji Šādam lietotājam norāda konta veidu Sistēmkonts.       Lappusē Tiesības norāda, kuras firmas datiem būs pieeja un ar kādu lomu.       Visbeidzot var veidot WEB lietotāju. Sistēma - Administrēt - WEB lietotāji Lappusa Pamatinformācija Arī šeit konta veids jānorāda Sistēmkonts, kā arī WEB lietotājs jāsasaista ar Horizon lietotāju. Lappusē Firmas un objekti norāda, kura šim pieslēgumam būs noklusētā firma. Lappusē Atļautās saskarnes atzīmē "piešķirtās" un norāda saskarni "Vispārējā integrācija", ja vien nav izveidota atsevišķa saskarne topošajai integrācijai. Vairāk par saskarnēm lasīt šeit.      

Lai izgūtu no Horizon datus par darbinieku prombūtnēm, var izmantot Horizon atskaiti Plānotās prombūtnes (Atskaites - Personāla uzskaite - Plānotās prombūtnes). Šajā atskaitē pieejami dati gan par notiekošām prombūtnēm, gan plānotām (pieteiktām). Ja nepieciešams, iespējams paskatīties arī uz pagātnē notikušām prombūtnēm.   REST vaicājuma piemērs:     ...rest/TpuAbsencesSL/query?columns= DOKT_ID,DOKT_KODS,DOKT_NOSAUK,ERS_TNUM,ERS_PK_PERS,ERS_FNAME,ERS_LNAME,PSADM_NOSAUK,PSAMA_NOSAUK,ABS_STATUS,ABS_DAT_FROM,ABS_DAT_TO,ABS_DOC_PK,AISL_PK_PERS,AISLP_FNAME,AISLP_LNAME,AIZV_DATLIDZ, AIZV_DATNO, AIZV_PIEZIMES&filter=ABS_STATUS ne 3&orderby=ABS_DAT_FROM desc&NO_DAT=2024-06-01&LIDZ_DAT=2024-06-15     DOKT_ID,DOKT_KODS,DOKT_NOSAUK - prombūtnes dokumenta pamatveids, dokmenta tipa kods, nosaukums; ERS_PK_PERS,ERS_FNAME,ERS_LNAME - prombūtnē esošā darbinieka personas kartītes PK (identifikators), vārds, uzvārds; PSADM_NOSAUK,PSAMA_NOSAUK - prombūtnē esošā darbinieka pamatslodzes struktūrvienība, amats; ABS_STATUS - prombūtnes statuss (Sagatave - 3; Ieplānota - 2; Apstiprināta - 1; Sākusies - 0) ABS_DAT_FROM,ABS_DAT_TO - prombūtnes sākuma un beigu datums; AISL_PK_PERS,AISLP_TNUM,AISLP_FNAME,AISLP_LNAME,AIZV_DATLIDZ, AIZV_DATNO, AIZV_PIEZIMES - ziņas par aizvietotāju - PK(identifikators), tabeles numurs, vārds, uzvārds, aizvietošanas periods no/līdz.   Filtra nosacījums "ABS_STATUS ne 3" - neatlasīt tās prombūtnes, kas ir statusā "Sagatave".

Datu sinhronizācijas mehānisms ir paredzēts darbam ar Horizon klasifikatoriem, lai saņemtu informāciju par tajos veiktajām izmaiņām. Sinhronizācija darbojas pēc šādas shēmas: ar GET pieprasījumu uz kādu no apakšresursiem, piemēram, changed nolasa datus; izpilda POST pieprasījumu uz to pašu apakšresursu, fiksējot saņemtās vērtības. Klasifikatori Horizon pusē ir, piemēram, klientu saraksts (TDdmKlPamatDat), nomenklatūru saraksts (TNdmNomSar), realizācijas rēķinu saraksts (TNdmRekSar) utt. Tiklīdz tiek veiktas izmaiņas kādam klasifikatora ierakstam, piemēram, nomenklatūrai mainās nosaukums, klienta kartītē tiek ierakstīts e-pasts, rēķinam tiek piesaistīts maksājums, šim ierakstam datubāzē tiek palielināta counter vērtība, attiecīgi sync pēc šīm vērtībām saprot, kuri ieraksti ir mainīti. Uzreiz jāpiemin, ka ne visas veiktās darbības klasifikatora ierakstam maina counter vērtību, kā piemēram, nomenklatūru atlikumu izmaiņas - tās nav izmaiņas nomenklatūras kartītē, bet gan tās atlikumos, kas tiek saglabāti citā tabulā. Nomenklatūru atlikumu atskaite (TNdmNatlSL) nav klasifikators, tā ir atskaite, tajā dati tiek izsaukti no vairākām tabulām, veikti aprēķini un rezultāts attēlots lietotājam. Te sync resursi nav izmantojami, tas neatlasa datus pēc izmaiņām atlikumos, bet gan pēc izmaiņām tieši nomenklatūras kartītē.   Detalizētāks apraksts par sinhronizāciju atrodams dokumentācijā.

Šajā rakstā pieejams dokuments par to, kas jāzina, lai veiktu sistēmu integrāciju, izmantojot REST.

Ja dati par jauniem darbiniekiem primāri tiek ievadīti, piemēram, personāla atlases sistēmā, dokumentu pārvaldības sistēmā vai kādā citā uzņēmumā izmantotā datu bāzē, tad, lai nepārvadītu darbinieka datus manuāli, iespējams izveidot jaunu darbinieka kartīti Horizon, izmantojot Rest.   Šeit apskatīta darbinieka kartītes izveide Horizon sarakstā Pamatdati -> Personāla uzskaite -> Personu kartītes.   Pievienojot jaunu personas kartīti, obligāti jānorāda, ar kuru dokumenta tipu tā tiks veidota. Horizon var būt izveidoti vairāki personas kartīšu dokumentu tipi, piemēram, rezidentiem (ar personas koda pārbaudi) un nerezidentiem. Personu kartīšu dokumentu tipu sarakstu var iegūt:       GET ../rest/TdmDarbBaseBL/template       POST vaicājuma piemērs personas kartītes izveidei ar minimālo obligāti aizpildāmo informācijas apjomu:       POST .../rest/TdmDarbBaseBL/template/{pk} <resource> <entity> <PK_DOKT> <href>/rest/TdmDocType/{pk}</href> </PK_DOKT> <PAMV_ID>6010</PAMV_ID> <TNUM>0000</TNUM> <FNAME>Vārds</FNAME> <LNAME>Uzvārds</LNAME> <PERS_KODS>000000-00000</PERS_KODS> <DZIM_DAT>YYYY-MM-DD</DZIM_DAT> <DZIMUMS>1</DZIMUMS> <STATUSS>0</STATUSS> <PK_VALSTS> <href>/rest/TdmBLDValsts/1</href> </PK_VALSTS> <admPerBaseBL> <row> <SPEKA_NO>YYYY-MM-DD</SPEKA_NO> <DOCOPYADR>0</DOCOPYADR> </row> </admPerBaseBL> <pudmBildeBL> <row> <BILDE> <data></data> </BILDE> </row> </pudmBildeBL> </entity> </resource>       {pk} -  Vajadzīgā personas kartītes dokumenta tipa primārā atslēga; DZIMUMS - Sieviete='1', Vīrietis='2'; STATUSS - Sagatave='0', Apstiprināts='1'; TdmBLDValsts/{pk} rezidences valsts no valstu saraksta Horizon (Pamatdati -> Uzņēmums -> Valsts); TNUM - tabeles (kartītes) numurs - var nebūt, ja Horizon ir izveidots automātisks numerators; BILDE - personas fotoattēla dati base64 kodējumā.  

Dažādām ar personāla vadību saistītām integrācijām ir nepieciešams no Horizon sistēmas izgūt datus par darbiniekiem. Piemēram, ārpus Horizon tiek uzturēta darbinieku kontaktu grāmata, tiek ģenerētas obligāto veselības pārbaužu kartes vai drukātas darba apliecības. Lai to izdarītu, nepieciešami darbinieku dati, tādi kā pamatinformācija, kontaktinformācija, amats utml.   Vispirms jāsaprot, cik daudz, kādi tieši un cik detalizēti dati būs nepieciešami.    Horizon sistēmā darbinieka dati tiek uzkrāti vairākos sarakstos ar atšķirīgu detalizāciju un datu apjomu. Atkarībā no tā, kādus datus nepieciešams izgūt, var izmantot šādus sarakstus:   1. Personu kartītes Pamatdati -> Personāla uzskaite -> Personu kartītes Sarakstā atrodami darbinieka pamatdati, piemēram, tabeles (kartītes) numurs, vārds, uzvārds, personas kods, dzimums, kontaktinformācija, adrese, kā arī ar darbinieku saistīti dati, piemēram, identifikācijas, izglītības dokumenti u.c. No šī saraksta iespējams izgūt arī informāciju par darbinieka vienām galvenajām tiesiskajām attiecībām un šo tiesisko attiecību pamata amata datiem.   PIEMĒRI:         1. Šobrīd aktīvo darbinieku kontaktinformācija ar pamata amatu un struktūrvienību: GET .../rest/TdmDArbSar/query?CRITERIA=AKTIVIE&columns=ERS_PK_PERS,ERS_TNUM,ERS_FNAME,ERS_LNAME,ERS_PERS_KODS,ERS_DZIMUMS,ERS_EPASTS,ERS_TELEFONS,PSADM_NOSAUK,PSAMA_NOSAUK CRITERIA=AKTIVIE - atlasīt tikai darbiniekus ar spēkā esošām tiesiskajām attiecībām. ERS_PK_PERS - personas kartītes sistēmas ID (primārā atslēga); ERS_TNUM - personas kartīties (tabeles) numurs; ERS_FNAME,ERS_LNAME - vārds, uzvārds; ERS_PERS_KODS - personas kods; ERS_DZIMUMS - dzimums (sieviete="1", vīrietis="2") ERS_EPASTS - darba e-pasts; ERS_TELEFONS - darba telefons; PSADM_NOSAUK - administratīvā struktūrvienība (pamatslodzes); PSAMA_NOSAUK - amata nosaukums (pamatslodzes).         2. Šādu vaicājumu var papildināt ar vēl citiem laukiem un filtriem, piemēram, atlasīt tikai tos darbiniekus, kuriem tiesiskajās attiecībās Ienākuma veids ir darba alga (rezidenti un nerezidenti): GET .../rest/TdmDArbSar/query=AKTIVIE&columns=ERS_PK_PERS,ERS_TNUM,ERS_FNAME,ERS_LNAME,ERS_EPASTS,ERS_TELEFONS,PSADM_NOSAUK,PSAMA_NOSAUK,LAT_PK_LIGA,LAT_NUMURS,LAT_SAK_DAT,LAT_BEIG_DAT,IEN_KODS&filter=inlist(IEN_KODS, '1001', '15', '1066') inlist(IEN_KODS, '1001', '15', '1066') - ienākumu veids ir VIENS NO norādītajām vērtībām.   LAT_PK_LIGA - tiesisko attiecību sistēmas ID (primārā atslēga); LAT_NUMURS - tiesisko attiecību numurs; LAT_SAK_DAT,LAT_BEIG_DAT - tiesisko attiecību no/līdz datumi; IEN_KODS - ienākumu veida kods.       3. Kā izgūt darbinieka fotoattēlu?  Ja pie darbinieka kartītes pievienota fotogrāfija, to iespējams izgūt, piemēram, base64 kodējumā. Jāveido pieprasījums personas kartītei (entītes ierakstam), iekļaujot šādu parametru: GET ...rest/TdmDarbBaseBL/{pk}?bindata=embed {pk} - personas kartītes sistēmas ID (primārā atslēga) Pieprasījuma atbildē tiks atgriezts bināro lauku saturs base64 kodējumā.   2. Darbinieku tiesisko attiecību dati Pamatdati -> Personāla uzskaite -> Tiesiskās attiecības Sarakstā apkopota informācija par visām darbinieka tiesiskajām attiecībām - darba, uzņēmuma, autoratlīdzības u.c. līgumiem. Sarakstā iespējams izgūt, piemēram, līgumu numurus, veidus, sākuma, beigu datumus, ziņas par pārbaudes laiku, ja tāds noteikts utml. Šo sarakstu var izmantot, ja ar vienu darbinieku vienlaikus ir noslēgts vairāk par vienu darba/uzņēmuma līgumu. Sarakstā nebūs redzami darbinieki, kuriem nav spēkā nevienas tiesiskās attiecības. Šajā sarakstā var izgūt arī darbinieka pamatdatus, kontaktinformāciju u.c. datus no personas kartītes, kā arī ziņas par katra darba līguma pamatslodzi (amata nosaukums, profesija, administratīvā struktūrvienība, atalgojums utml.).   PIEMĒRS: GET ...rest/TdmLigAttSar/query?CRITERIA=AKTIVIE&columns=ERS_TNUM,ERS_FNAME,ERS_LNAME,ERS_PERS_KODS,LAT_PK_LIGA,LAT_NUMURS,LAT_SAK_DAT,LAT_BEIG_DAT,LAT_PARB_BEIG,IEN_KODS,PSADM_NOSAUK,PSAMA_NOSAUK   CRITERIA=AKTIVIE - atlasīt tikai spēkā esošas tiesiskās attiecības.   ERS_TNUM - personas kartīties (tabeles) numurs; ERS_FNAME,ERS_LNAME - vārds, uzvārds; ERS_PERS_KODS - personas kods; LAT_PK_LIGA - tiesisko attiecību sistēmas ID (primārā atslēga); LAT_NUMURS - tiesisko attiecību numurs; LAT_SAK_DAT,LAT_BEIG_DAT - tiesisko attiecību sākuma, beigu datums; IEN_KODS - ienākumu veida kods; PSADM_NOSAUK - administratīvā struktūrvienība (pamatslodzes); PSAMA_NOSAUK - amata nosaukums (pamatslodzes).   3. Darbinieku amatu dati (slodzes) Pamatdati -> Personāla uzskaite -> Personu amatu dati Sarakstā apkopota informācija par darbinieka visu tiesisko attiecību visiem amatu datiem - pamatslodzēm un papildslodzēm, ja tādas ir - amatu nosaukumi, profesijas, administratīvās struktūrvienības, atalgojums utt. Šo sarakstu izmanto, ja nepieciešama detalizēta informācija par visām darbinieka slodzēm, piemēram, ja darbinieks strādā vienlaikus vairākos amatos, struktūrvienībās. Sarakstā iespējams izgūt arī datus no darbinieka personas kartītes (pamatdatus, kontaktinformāciju u.c.), kā arī datus par katras slodzes tiesiskajām attiecībām (līguma numuru, sākuma, beigu datumus u.c.). Sarakstā nebūs redzami darbinieki, kuriem nav spēkā esošu amata datu.    PIEMĒRS: GET ...rest/TadmSlSar/query?CRITERIA=CRIT_LAT_AKTIVIE&columns=ERS_TNUM,ERS_FNAME,ERS_LNAME,LAT_NUMURS,PK_SLODZE,DOK_NR,SAK_DAT,BEIG_DAT,PK_APMAKSA,SUMMA,STR_NOSAUK,VAM_NOSAUK,SL_TIPS   CRITERIA=CRIT_LAT_AKTIVIE - darbiniekam ir vismaz vienas spēkā esošas tiesiskās attiecības.   ERS_TNUM - personas kartīties (tabeles) numurs; ERS_FNAME,ERS_LNAME - vārds, uzvārds; LAT_NUMURS - tiesisko attiecību numurs; PK_SLODZE - personas amata datu sistēmas ID (primārā atslēga); DOK_NR - personas amata datu numurs; SAK_DAT,BEIG_DAT - personas amata dati "no"/"līdz"; PK_APMAKSA - apmaksas veids:            Alga proporcionāli dienām = 1            Stundas tarifa likme = 2            Gabaldarbs = 3            Dienas apmaksa = 4            Alga proporcionāli stundām = 5 SUMMA - likme (atalgojuma likme); STR_NOSAUK - struktūrvienības nosaukums; VAM_NOSAUK - amata nosaukums; SL_TIPS - slodzes tips (pamatslodze = 1; papildslodze = 2)   4. Atskaites Darbinieki periodā un Personu amatu dati periodā Atskaites -> Personāla uzskaite -> Statistika -> Darbinieki periodā Atskaites -> Personāla uzskaite -> Statistika -> Personu amatu dati periodā   No šīm atskaitēm izgūstama tā pati informācija, kas no personu kartīšu un amatu datu sarakstiem. Atšķirība ir tajā, ka atskaitei jānorāda periods, par kuru vēlamies redzēt datus, tādēļ no atskaitēm būs iespējams izgūt vēsturiskos datus, piemēram, par darbinieku skaitu, amatiem pirms gada utml.    PIEMĒRI: GET ...rest/TdmDArbSar2/query?NO_DAT=2022-11-01&LIDZ_DAT=2022-11-30&columns=ERS_TNUM,ERS_FNAME,ERS_LNAME,ERS_PERS_KODS,ERS_DZIMUMS,IEN_KODS,LAT_NUMURS,LAT_SAK_DAT,LAT_BEIG_DAT,PSADM_NOSAUK,PSAMA_NOSAUK GET ...rest/TadmSlSar2/query?NO_DAT=2022-11-01&LIDZ_DAT=2022-11-30&columns=ARD_TNUM,ERS_FNAME,ERS_LNAME,ERS_PERS_KODS,ERS_DZIMUMS,LAT_NUMURS,LAT_SAK_DAT,LAT_BEIG_DAT,SLODZE,DOK_NR,SAK_DAT,BEIG_DAT,SUMMA,STR_NOSAUK,VAM_NOSAUK