Zināšanu bāze Integrācija

Sākot ar 680 versiju, REST ir pieejama jauna funkcija, kas ļaus mainīt saistību dokumenta apmaksas termiņu. Šī darbība ir veidota pēc līdzības ar Horizon pieejamo darbību Dokumenti -> Apgāde/Realizācija -> Preču dokumenti -> Darbības -> Mainīt apmaksas termiņu, un tagad būs pieejama arī integrācijām. Apmaksas termiņu iespējams mainīt izpildītiem un grāmatotiem debitoru/kreditoru saistību dokumentiem. Jāņem vērā, ka apmaksas termiņa maiņa var ietekmēt kavējuma naudas aprēķinus, apmaksas kontroļu rezultātus un atskaites, kurās tiek izmantots dokumenta apmaksas termiņš.  Darbības izsaukšana REST Apmaksas termiņa maiņa tiek veikta konkrētā dokumenta entītes resursā, izmantojot metodi changeDueDate. Metodes izsaukšanas piemērs dokumenta pamatveidam Rēķins par pakalpojumiem:   POST ../rest/TNdmPvzRek/changeDueDate Metodes izsaukšanas piemērs dokumenta pamatveidam Saņ. rēķins par pakalpojumiem:   POST /rest/TNdmPvzRekS/changeDueDate Pieprasījuma piemērs:   <resource>    <aPkDok>{PK}</aPkDok>    <aDueDate>yyyy-mm-dd</aDueDate>    <aDueDateChangeAlgorithm>0</aDueDateChangeAlgorithm> </resource>   Pieprasījuma parametru apraksts: aPkDok – dokumenta sistēmas ID, kuram nepieciešams mainīt apmaksas termiņu ; aDueDate – jaunais apmaksas termiņa datums; aDueDateChangeAlgorithm – apmaksas termiņa noteikšanas veids: 0 – izmantot parametrā aDueDate norādīto datumu; 1 – izmantot dokumentam piesaistītā līguma apmaksas termiņu. Ja tiek izmantots algoritms 1, parametrs aDueDate nav obligāts — norādītā vērtība netiks izmantota, jo termiņš tiks noteikts no dokumentam piesaistītā līguma.   

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.  

Interneta veikalā veiktos darījumus Horizon var reģistrēt noliktavas modulī ar dokumentu "Pārdošanas pavadzīme". Ja Horizon ir vairāki pārdošanas pavadzīmes dokumentu tipi, tad Horizon lietotāji nosaka, kuru dokumentu tipu integrācijai izmantot. Pārdošanas pavadzīmes dokumentu tipu sarakstu iespējams iegūt ar šādu vaicājumu.   GET ../rest/TNdmPvzSale/template Pārdošanas pavadzīmi veido ar sekojošu vaicājumu.   POST ../rest/TNdmPvzSale/template/{pk} <resource> <entity> <PK_DOKT>5</PK_DOKT> <PAMV_ID>2711</PAMV_ID> <PK_ESPATS>4</PK_ESPATS> <PK_KLIENTS>66</PK_KLIENTS> <DAT_DOK>2025-11-21</DAT_DOK> <PK_VAL>3</PK_VAL> <NdmPvzAddition> <PK_ADRESE>32</PK_ADRESE> </NdmPvzAddition> <qryPamat> <row> <PAMAT>Piezīmes</PAMAT> </row> </qryPamat> <tblRindas> <row> <RN_VEIDS>0</RN_VEIDS> <PK_NOM>1</PK_NOM> <DAUDZ>10</DAUDZ> <FCENA>4.69</FCENA> </row> </tblRindas> </entity> </resource> PK_ESPATS - noliktavas ID, ../rest/TNdmNolSar/default PK_KLIENTS - klienta kartītes sistēmas ID, kā atrast klienta ID DAT_DOK - pavadzīmes datums PK_VAL - valūtas ID PK_ADRESE - klienta piegādes adreses ID PAMAT - pavadzīmes piezīmes RN_VEIDS - rindas veids, 0 - nomenklatūra PK_NOM - nomenklatūras ID, kā noskaidrot preces ID  DAUDZ - daudzums FCENA - cena. Ja lauku nenorāda, cena tiek noteikta automātiski

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ās, kas izmantoto klientu saraksta datus, var rasties nepieciešamība papildināt klienta kartīti ar jauniem saistīto datu ierakstiem. Šajā rakstā apskatīsim vaicājumu ar kuru palīdzību caur REST var pievienot klienta kartītes kontaktpersonas.   Jaunas kontaktpersonas pievienošana   POST ../rest/TdmDKPers/template/191 POST BODY <resource> <entity> <PK_DOKT> <href>/rest/TdmDocType/191</href> </PK_DOKT> <VARDS>Jānis</VARDS> <KONTAKTP>Bērziņš</KONTAKTP> <TELEFONS>67067067</TELEFONS> <MOBTEL>20220230</MOBTEL> <EPASTS>[email protected]</EPASTS> <dmDContactRows> <row> <PAMATP>0</PAMATP> <PK_KLIENTS>51</PK_KLIENTS> <TIPS>3</TIPS> </row> </dmDContactRows> </entity> </resource> PAMATP – Galvenā kontaktpersona (Jā – 1; Nē – 0) PK_KLIENTS - Klienta kartītes sistēmas ID TIPS - Kontaktpersonas tips (Klienta kartīte - 3)  

Integrācijās, kas izmantoto klientu saraksta datus, var rasties nepieciešamība papildināt klienta kartīti ar jauniem saistīto datu ierakstiem. Šajā rakstā apskatīsim vaicājumu ar kuru palīdzību caur REST var pievienot klienta kartītes bankas kontus   Jauna bankas konta pievienošana   POST ../rest/TDdmCustAccount/template POST BODY <resource> <entity> <PK_KLIENTS>51</PK_KLIENTS> <PK_BANKA>17</PK_BANKA> <NUMURS>LVHABA000222333444555</NUMURS> <AKTIVS>0</AKTIVS> <PK_VAL>8</PK_VAL> </entity> </resource> PK_KLIENTS - Klienta kartiņas sistēmas ID ID PK_BANKA - Bankas sistēmas ID ID PK_VAL - Valūtas sistēmas ID   Horizon ievadītās banku  sistēmas ID var noskaidrot ar šādu vaicājumu   GET ..rest/TDdmBankas/query?Columns=B_PK_BANKA,B_KODS,B_NOSAUK,BKT_KODS,B_TIPS,B_STATUSS B_PK_BANKA – Bankas sistēmas ID B_STATUSS – Bankas statuss (Aktīvs – 0; Neaktīvs - 1)   Horizon ievadītās valūtu sistēmas ID var noskaidrot ar šādu vaicājumu   GET ..rest/TsdmValSar/query?Columns=SVAL_PK_VAL,SVAL_KODS,SVAL_NOS_VSK,SVAL_NOS_DSK,SVAL_S_NOS_VSK,SVAL_S_NOS_DSK SVAL_PK_VAL – Valūtas sistēmas ID SVAL_KODS – Valūtas kods

Integrācijās, kas izmantoto klientu saraksta datus, var rasties nepieciešamība papildināt klienta kartīti ar jauniem saistīto datu ierakstiem. Šajā rakstā apskatīsim vaicājumu ar kuru palīdzību caur REST var pievienot klienta kartītes adreses.   Jaunas adreses pievienošana   POST ../rest/TNdmAdr/template POST BODY <resource> <entity> <PK_KLIENTS>51</PK_KLIENTS> <STATUSS>1</STATUSS> <ADRESE1>"Priedes 4"</ADRESE1> <ADRESE2>Silakrogs, Ropažu pagasts</ADRESE2> <ADRESE3>Ropažu novads</ADRESE3> <PASTA_IND>LV-2133</PASTA_IND> <PK_VALSTS>1</PK_VALSTS> <LEG_ADR>1</LEG_ADR> <POST_ADR>1</POST_ADR> </entity> </resource> PK_KLIENTS - Klienta kartītes sistēmas ID STATUSS - Adreses statuss (Aktīvs – 1; Neaktīvs 2) ADRESE1 - Ielas vai mājas numurs ADRESE2 - Ciema vai pagasta nosaukums ADRESE3 - Pilsētas vai novada nosaukums PASTA_IND - Pasta indekss PK_VALSTS - Valsts sistēmas ID LEG_ADR - Juridiskā adrese (1 – Ir; 2 - Nav) POST_ADR - Faktiskā adrese (1 – Ir; 2 - Nav)   Horizon ievadīto valstu sistēmas ID var noskaidrot ar šādu vaicājumu   GET ../rest/TdmSLDValsts/query?Columns=DV_PK_VALSTS,DV_KODS,DV_NOSAUK,DV_PK_VAL,DV_STATUSS DV_PK_VALSTS – Valsts sistēmas ID DV_NOSAUK – Valsts nosaukums

Interneta veikalā veiktos pasūtījums Horizon visbiežāk reģistrē loģistikas modulī ar dokumentu "Pieprasījums". Ja Horizon ir vairāki pieprasījuma dokumentu tipi, tad Horizon lietotāji nosaka, kuru dokumentu tipu integrācijai izmantot. Pieprasījumu dokumentu tipu sarakstu iespējams iegūt ar šādu vaicājumu. GET ../rest/TLgPiepDBL/template Loģistikas pieprasījumu veido ar sekojošu vaicājumu. POST ../rest/TLgPiepDBL/template/{pk} <resource> <entity> <PK_DOKT>501</PK_DOKT> <PAMVID>7162</PAMVID> <PK_KLIENTS>30</PK_KLIENTS> <DOC_DATE>2024-01-28</DOC_DATE> <NUMURS>LD0158</NUMURS> <PK_ADRESE>20</PK_ADRESE> <NOTES>piezīmes</NOTES> <PK_NOL>4</PK_NOL> <LgPiepRows> <row> <RN_VEIDS>0</RN_VEIDS> <PK_NOM>1</PK_NOM> <DAUDZ>5</DAUDZ> <FCENA>35</FCENA> </row> </LgPiepRows> </entity> </resource>   PK_KLIENTS - klienta kartītes sistēmas ID, kā atrast klienta ID DOC_DATE - pieprasījuma datums NUMURS - pieprasījuma numurs PK_ADRESE - klienta piegādes adreses ID NOTES - piezīmes PK_NOL - noliktavas ID, ../rest/TNdmNolSar/default RN_VEIDS - rindas veids, 0 - nomenklatūra PK_NOM - nomenklatūras ID, kā noskaidrot preces ID  DAUDZ - daudzums FCENA - cena. Ja lauku nenorāda, cena tiek noteikta automātiski  

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.      

Horizon iespējams vienā datubāzē veikt vairāku uzņēmumu uzskaiti. Iespējami divi dažādi varianti - vairāku nodokļu maksātāju (VNM) režīms jeb iestāžu režīms un firmu režīms.    Vairāku nodokļu maksātāju režīms jeb iestāžu režīms nozīmē, ka vairāki uzņēmumi tiek uzskaitīti vienā datubāzes apgabalā, tiem ir kopēji pamata klasifikatori un katram dokumentam tiek norādīts kurai iestādei tas atbilst. Strādājot ar datubāzi šādā režīmā nepieciešams dokumentu sarakstus filtrēt pēc iestādes lauka. Iestāžu sarakstu iespējams iegūt ar šādu vaicājumu:   GET .../rest/TsarDIestade   Piemērs ar realizācijas rēķinu atlasi filtrējot pēc iestādes.   GET .../rest/TNdmRekSar/query?filter=IEST_PK_IESTADE eq 2&columns=D.DOK_NR,D.DAT_DOK,D.K.NOSAUK,D.SUMMA   Firmus režīms nozīmē, ka vienā datubāzē katrs uzņēmums tiek uzskaitīts nodalītā datubāzes apgabalā - firmā.  Strādājot ar datubāzi šādā režīmā iespējams izmantot atsevišķu lietotāju katrai firmai vai arī veidot vienu lietotāju ar vairākām piesaistītām firmām. Sīkāk par lietotāju veidošanu un firmu piesaistīšanu lasīt šeit.   Ja tiek izmantots lietotājs ar piekļuvēm vairākām firmām, tad pieslēdzoties primāri tiek atlasīta noklusētā lietotāja firma. Informācija par firmu, kuras dati tiek atdoti pieejama galvenē Organization. Ja nepieciešams pieslēdzoties norādīt konkrētu firmu, tad jāizmanto speciālā autentifikācija un parametrs firmaid. Šī brīža aktīvo firmu iespējams apskatīt ar šādu vaicājumu:     GET .../rest/user/organization/current     Lietotājam pieejamās firmas iespējams apskatīt ar šādu vaicājumu:   GET .../rest/user/organization   Ja nepieciešams nomainīt aktīvo firmu, to iespējams izdarīt ar šādu vaicājumu:   POST .../rest/user/organization/change <resource> <PK_FIRMA>4</PK_FIRMA> </resource>  

Viens no visbiežāk izmantotajiem Horizon pamatdatu sarakstiem ir klientu saraksts un šis saraksts tiek izmantots arī daudzās REST integrācijās. Zemāk apskatīsim pamata vaicājumus ar kuriem no Horizon var izgūt aktuālo klientu sarakstu un vaicājumus ar kuriem caur REST var pievienot jaunus klientus. 1. Esošu klientu kartiņu datu izgūšana Klientu saraksts ir galvenais saraksts no kurienes izgūt informāciju par klientiem (Pamatdati -> Klienti -> Klientu saraksts). Ar zemāk esošo vaicājumu iespējams izgūt visas aktīvās debitoru klientu kartiņas.   GET ../rest/TDdmKlSar/query?filter=K_STATUSS eq 0 and K_DBKRPAZ eq 1&columns=K.PK_KLIENTS,K_KODS,K_NOSAUK,K_EPASTS,K_TELEFONS,K_MOBTEL,K_UNI_NR,K_PVN_REGNR,K_DBKRPAZ,K_STATUSS K_STATUSS - filtrēšana pēc klienta kartītes statusa. 0 - aktīvās kartītes K_DBKRPAZ - filtrēšana pēc klienta norēķinu veida (Debitors - 1; Kreditors - 2; Neuzskaita - 0) K_PK_KLIENTS - klienta kartītes sistēmas ID K_UNI_NR - klienta universālais numurs. Apvienots lauks kurā tiek rādīts uzņēmuma reģistrācijas numurs vai privātpersonas personas kods   Ar zemāk esošo vaicājumu var izgūt informāciju par vienu konkrētu aktīvu klienta kartiņu, kas filtrēta pēc klienta reģistrācijas vai personas koda.   GET ../rest/TDdmKlSar/query?filter=K_UNI_NR eq '40003734170' and K_STATUSS eq 0&columns=K.PK_KLIENTS,K_KODS,K_NOSAUK,K_EPASTS,K_TELEFONS,K_MOBTEL,K_UNI_NR,K_PVN_REGNR,K_DBKRPAZ,K_STATUSS K_STATUSS - filtrēšana pēc klienta kartītes statusa. 0 - aktīvās kartītes K_UNI_NR - filtrēšana pēc klienta universālā numura (reģistrācijas numurs vai privātpersonas personas kods)   2. Jaunu klientu kartiņu izveidošana Klientiem var būt izviedoti vairāki klientu kartiņas dokumenta tipi ar savām definētam noklusētajām vērtībām. Veidojot jaunas klienta kartiņas ir svarīgi izvēlēties atbilstošo klientu kartiņas dokumenta tipu. Visus pieejamos klienta kartiņu dokumenta tipus varat noskaidrot ar šādu vaicājumu.   GET ../rest/TDdmCustomer/template Šādā veidā tiek izgūta informācija par visiem klientu kartītēs pieejamiem laukiem, taču ļoti bieži pilnīgi visus klienta kartiņā pieejamos laukus nav nepieciešams aizpildīt.   GET ../rest/TDdmCustomer/template/2 Kad ir atrasts atbilstošais klienta kartiņas dokumenta tipa template, nepieciešams aizpildīt Jums svarīgo informāciju. Veidojot jaunus klientus caur REST, laba prakse ir iesūtīt tikai Jums nepieciešamo informāciju un neizmantotos laukus no šablona dzēst.   Uzņēmuma klienta kartiņas izveide POST ../rest/TDdmCustomer/template/2 POST Body <resource> <entity> <PK_DOKT>2</PK_DOKT> <KODS>0001</KODS> <TIPS>3</TIPS> <NOSAUK>Visma Enterprise SIA</NOSAUK> <REG_NR>40003734170</REG_NR> <PVN_REGNR>LV40003734170</PVN_REGNR> <PK_VALSTS>1</PK_VALSTS> <PK_VAL>3</PK_VAL> <DBKRPAZ>1</DBKRPAZ> <EPASTS>[email protected]</EPASTS> <WWWLAPA>www.visma.lv</WWWLAPA> <TELEFONS>67116211</TELEFONS> <MOBTEL>22334455</MOBTEL> </entity> </resource>   Privātpersonas klienta kartiņas izveide POST ../rest/TDdmCustomer/template/2 POST Body <resource> <entity> <PK_DOKT>2</PK_DOKT> <KODS>0002</KODS> <TIPS>6</TIPS> <VARDS>Jānis</VARDS> <UZVARDS>Bērziņš</UZVARDS> <PERSKODS>112233-11223</PERSKODS> <PK_VALSTS>1</PK_VALSTS> <PK_VAL>3</PK_VAL> <DBKRPAZ>1</DBKRPAZ> <EPASTS>[email protected]</EPASTS> <TELEFONS>67226733</TELEFONS> <MOBTEL>22334455</MOBTEL> </entity> </resource>   PK_DOKT - Dokumenta tipa sistēmas ID TIPS - Klienta kartiņas tips (Uzņēmums - 3, Privātpersona - 6, Individuālais uzņēmums - 4, Vienreizējs - 8 ) KODS - ja klientam dokumenta tipā ir definēts klientu numerators var atstāt tukšu, Horizon to automātiski aizpildīs PERSKODS - Ja klienta kartīte ir privātpersona, tad šeit tiek ievadīts personas kods  PK_VALSTS - Klienta valsts sistēmas ID PK_VAL - Klienta valūtas sistēmas ID standarta sākumkonfigurācija EUR - 3 DBKRPAZ - Norēķinu veids. (Debitors - 1; Kreditors - 2; Neuzskaita - 0)

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".

Ienākošo maksājumu apstrādi no bankām Horizon veic maksājumu importa funkcionalitāte. Ja uzņēmums izmanto kādus maksājumu starpniekus, tad dažkārt maksājums bankā ienāk kopsummā un grāmatvedības uzskaitē tas ir jāsadala pret katru konkrēto klientu/rēķinu. Šādā gadījumā iesakām izmantot sadarbības partnera "virtuālo" bankas kontu, kurā uzskaitīt detalizētos maksājumus un ar bankas pārvedumu ievadīt kopējo maksājumu uzņēmuma bankas kontā. Sīkāk par šo risinājumu šeit.    Šāda risinājuma gadījumā sadarbības partneris ienākošos maksājumus katram samaksājušajam klientam var pievienot izmantojot REST.   Pievienojot ienākošo maksājumu obligāti jānorāda ar kuru dokumenta tipu tas tiks veidots. Ja Horizon ir vairāki dokumentu tipi, tad Horizon lietotāji nosaka kuru dokumentu tipu integrācijai izmantot. Ienākošo maksājumu dokumentu tipu sarakstu iespējams iegūt:  GET ../rest/TDdmInMu/template     POST …/rest/TDdmInMu/template/10 <?xml version="1.0" encoding="UTF-8" standalone="no"?> <entity> <resource> <PK_DOKT>10</PK_DOKT> <PAMV_ID>3306</PAMV_ID> <PK_R_ES>1</PK_R_ES> <PK_VAL>3</PK_VAL> <PK_KLIENTS>82</PK_KLIENTS> <DAT_DOK>2019-10-23</DAT_DOK> <DOK_NR>234654</DOK_NR> <SUMMA>100.00</SUMMA> <SUMMA_APM>100.00</SUMMA_APM> <PK_LIG>118</PK_LIG> <qryPamat> <row> <PAMAT>pamatojuma teksts</PAMAT> </row> </qryPamat> </entity> </resource>   PK_R_ES - bankas konta ID (..rest/TDdmSaviRekSarVisi/default) PK_VAL - valūtas ID (..rest/TsdmValSar/default) PK_KLIENTS - klienta kartītes sistēmas ID (../rest/TDdmKDebSar/default) DAT_DOK - maksājuma datums DOK_NR - maksājuma numurs SUMMA, SUMMA_APM - maksājuma summa PK_LIG - klienta līguma sistēmas ID, nav obligāts (..rest/TdmKllig/default) PAMAT - maksājuma pamatojums

Horizon dokumentiem, kuri ietekmē virsgrāmatu, pārsvarā ir 3 statusi - Sagatave, Izpildīts un Grāmatots. Izveidojot dokumentu tas ir statusā Sagatave. Pēc tam tos nepieciešams izpildīt un grāmatot, dažkārt to iespējams veikt arī integrācijas sistēmai.   Statusa nomaiņa tiek veikta konkrētā dokumenta entītes resursā.  Lai nodrošinātu, ka neviens cits lietotājs nav paralēli veicis darbības ar dokumentu, nepieciešams noskaidrot aktuālo dokumenta counter vērtību. To iespējams izdarīt konkrēto dokumentu atlasot pēc ID. Piemērs ar ienākošo maksājumu.   GET /rest/TDdmInMu/591 (maksājuma ID) Atbilde <description>Entītijas ieraksts</description> <title>234654</title> <entity xmlns="TDdmInMu.xsd" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="TDdmInMu.xsd TDdmInMu.xsd"> <PK_DOKT> <href>/rest/TdmDocType/10</href> </PK_DOKT> <PAMV_ID>3306</PAMV_ID> <COUNTER>0</COUNTER> <PK_DOK> <href rel="self">/rest/TDdmInMu/591</href> </PK_DOK> .....   Dokumentu izpildīšana   Dokumenta izpildi iespējams veikt ar metodi ExecuteFromKey   Piemērs ienākošajam maksājumam, kura resurss ir TDdmInMu.   POST ../rest/TDdmInMu/ExecuteFromKey <resource> <aKey>591</aKey> <CounterVal>0</CounterVal> <GramDate>2020-09-01</GramDate> </resource> aKey - dokumenta ID CounterVal - akutālā counter vērtība GramDate - izpildes datums   Dokumenta grāmatošana   Dokumenta izpildi iespējams veikt ar metodi BookFromKey   Piemērs ienākošajam maksājumam, kura resurss ir TDdmInMu.   POST .../rest/TDdmInMu/BookFromKey <resource> <aKey>591</aKey> <CounterVal>1</CounterVal> <aSchemaPk>1125</aSchemaPk> <DeleteDraft>1</DeleteDraft> </resource>   aKey - dokumenta ID CounterVal - akutālā counter vērtība aSchemaPk - kontēšanas shēmas ID (kontēšanas shēmu saraksts nav pieejamas REST API) DeleteDraft - 1 (kontējums tiks veidots pēc norādītās kontēšanas shēmas)

Bieži izmantots saraksts BI risinājumos ir Grāmatojumu saraksts, kurā datus lietderīgi filtrēt ar precīzu pulksteņlaiku. (Dokumenti -> Virsgrāmata -> Grāmatojumi)   Grāmatojumu saraksts satur daudz ierakstus, tāpēc iesakām iegūt datus tikai par grāmatojuma saraksta izmaiņām, kopš pēdējās datu ielādes.   Tā kā grāmatojums šodien var veikt dažādos datumos, tad svarīgi skatīties nevis uz grāmatojuma datumu, bet gan uz grāmatojuma transakcijas laiku, kas fiksē grāmatošanas notikuma laiku.   GET ../rest/TdmGramatSL/query?filter=SDE_LAIKS ge '2023-06-26T08:30:00.000%2B03:00'&columns=T_NOSAUK,K_NOSAUK,K_UNI_NR,D_DOK_NR,TEKSTS,DK_KODS,KK_KODS,SUMMA,PK_VAL,DS_KODS,KS_KODS,STATUSS,D_DOK_REGNR,DAT_GRP,SDE_LAIKS   T_NOSAUK - Dokumenta veids K_NOSAUK - Klienta nosaukums K_UNI_NR - Klienta universālais numurs (reģistrācijas kods vai personas kods) D_DOK_NR - Dokumenta numurs TEKSTS - Grāmatojuma pamatojums DK_KODS - Debeta konts KK_KODS - Kredīta konts SUMMA - Grāmatojuma summa PK_VAL - Valūta DS_KODS - Debeta struktūrvienības kods KS_KODS - Kredīta struktūrvienības kods STATUSS - (Normāls - 1; Sagatave - 2; Stornēts - 3; Stornējošs - 4) D_DOK_REGNR -  Dokumenta reģistrācijas numurs DAT_GRP - Grāmatošanas datums SDE_LAIKS - Transakcijas laiks Atkarībā no servera konfigurācijas nepieciešams vaicājumā nepieciešams norādīt korektu  laika joslu.  Piemēra servera laika josla ir definēta +3.00 stundas un REST tā tiek pierakstīta šādi “%2B03:00”   Sīkāk par saraksta filtrēšanas iespējām šeit.

Horizon dokumenta apmaksa starp dokumentiem tiek attēlota ar piesaistes izveidošanu to starpā. Sistēmā piesaistes ir iespējams veidot lietotājam manuāli izvēloties dokumentu vai veicot automātiskās piesaistes atbilstoši uzstādījumiem. Arī izmantojot integrāciju platformu iespējams izveidot piesaisti starp dokumentiem. Ja saistību vai maksājumu dokuments tiek izveidots izmantojot integrāciju, tad var būt nepieciešamība veidot piesaistes izmantojot integrāciju platformu   Piesaiste starp diviem konkrētiem dokumentiem   Piesaisti starp diviem dokumentiem iespējams izveidot ar metodi apmaksatFromKey. Metodei nepieciešams nodot maksājuma dokumenta ID, saistību dokumenta ID, valūtas ID. Ja summa tiek atstāta 0.00, tad sistēma izanalizēs, par kādu summa piesaisti iespējams izveidot.   Piemēru, ja piesaistītā darbība tiek veikta ienākošajam maksājumam ar citu saistību dokumentu, skatīt šeit.   Automātiska piesaiste, atbilstoši algoritmam   Horizon dokumentu sarakstos pieejama darbība "Piesaistīt automātiski", kas, atbilstoši uzstādījumiem vai izvēlētajai metodei, veic piesaistes piemeklējot atbilstošos piesaistāmos dokumentus.   Caur REST šo darbību iespējams veikt atbilstošo dokumentu resursiem, izmantojot metodi LinkDocAutomatically (pieejama no 600. versijas).    Metodei nepieciešams dokumenta ID (obligāts parametrs) un automātisko piesaistu metodes ID (ja padod -1, tad tiks izmantota noklusētā (pirmā atzīmētā no uzskaites parametriem).  Šo darbību paredzēts izpildīt pa vienam preču vai maksājuma dokumentam. Ja nepieciešams veikt piesaistes vairākiem dokumentiem, tad šī darbība jāizpilda cikliski katram dokumentam.   Piemērs, ja darbība "piesaistīt automātiski" tiek veikta ienākošajam maksājumam, izmantojot sistēmas uzstādījums.   POST /rest/TDdmInMu/LinkDocAutomatically <resource> <APkDoc>167894</APkDoc> <ALinkMethod>-1</ALinkMethod> </resource> Piesaistu metožu ID: 0 - Klients; 1 - Līgums; 2 - Klients, līgums; 3 - Klients, summa; 4 - Līgums, summa; 5 - Klients, līgums, summa; 6 - Klients, dok. Nr.; 7 - Klients, dok. Nr., summa; 8 - Klients, dok. Nr., līgums; 9 - Klients, dok. Nr., līgums, summa; 10 - Pa norēķinu grupām; 11 - Vecākajiem līguma dokumentiem un norēķinu grupām proporcionāli; 12 - Pa norēķinu grupām datumu secībā; 13 - Pēc atrastajiem rēķinu numuriem; 14 - Pēc atrastajiem rēķinu numuriem, summa

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ā.

Horizon izejošajiem rēķiniem (rēķiniem par pakalpojumiem) var būt definēti vairāki dokumentu tipi. Pievienojot jaunu rēķinu obligāti jānorāda ar kuru dokumenta tipu tas tiks veidots. Ja Horizon ir vairāki dokumentu tipi, tad Horizon lietotāji nosaka kuru dokumentu tipu integrācijai izmantot. Rēķinu dokumentu tipu sarakstu iespējams iegūt:  GET ../rest/TNdmPvzRek/template   PVN aprēķinu Horizon nevar koriģēt, tas ir iebūvēts sistēmas mehānisms. Rekomendējam uz Horizon padot skaitļus ar PVN. Šādā gadījumā nepieciešams izmantot dokumentu tipu, kurā PVN ir iekļauts.   Horizon lietotājs rēķinus ievada Dokumenti -> Realizācija -> Rēķinu saraksts.   POST ../rest/TNdmPvzRek/template/{pk} <resource>     <entity>         <PK_DOKT>27</PK_DOKT>         <PK_KLIENTS>162</PK_KLIENTS>         <DAT_DOK>2023-10-27</DAT_DOK>         <DOK_NR>test_REST</DOK_NR>         <PK_LIG>207</PK_LIG>         <APM_TERM>2023-10-31</APM_TERM>         <qryPamat>              <row>                  <PAMAT>Rēķina pamatojums</PAMAT>             </row>         </qryPamat>         <tblRindas>             <row>                 <RN_VEIDS>3</RN_VEIDS>                  <PK_NOM>36</PK_NOM>                 <DAUDZ>1</DAUDZ>                 <CENA>10</CENA>                 <SUMMA>10</SUMMA>                 <TEKSTS>Rindas piezīmes</TEKSTS>             </row>         </tblRindas>     </entity> </resource>   PK_KLIENTS - klienta kartītes sistēmas ID (../rest/TDdmKDebSar/default) PK_LIG - klienta līguma sistēmas ID, nav obligāts (rest/TdmKllig/default) RN_VEIDS - rindas tips, pakalpojums - 3 PK_NOM - pakalpojuma sistēmas ID (../rest/TNdmPakSar/default) CENA un SUMMA - aizpildīt nepieciešams vienu no vērtībām   Vairāk par darbu ar klienta kartītēm skatīt šo rakstu.