Īsā atbilde ir, ka sistēmu ar grāmatvedību var savienot daudz biežāk, nekā sākumā šķiet. Taču pareizais jautājums nav tikai, vai var pieslēgt grāmatvedības programmai, bet gan, ko tieši vēlamies nodot, cik bieži, ar kādu precizitāti un kurš būs atbildīgs, ja dati nesakritīs. Vienai komandai pietiek ar regulāru rēķinu eksportu CSV failā, citai vajag pilnībā automātisku klientu, preču, noliktavas un maksājumu sinhronizāciju.

Praksē lielākā kļūda ir pieņemt, ka “integrācija” nozīmē vienu un to pašu visiem. Tas nenozīmē. Tāpēc pirms lēmuma mēs vienmēr iesakām aprakstīt savu procesu no dokumenta rašanās līdz grāmatošanai, un tikai tad izvēlēties tehnisko risinājumu. Ja šo soli izlaiž, var sanākt, ka pieslēgums tehniski darbojas, bet biznesa procesam neder.

Ko patiesībā nozīmē pieslēgt sistēmu grāmatvedības programmai

Kad uzņēmumi jautā, vai sistēmu var savienot ar grāmatvedību, viņi bieži domā dažādas lietas.

Pilna integrācija parasti nozīmē, ka divas sistēmas apmainās ar datiem automātiski un pēc noteiktiem noteikumiem. Piemēram, no pasūtījumu sistēmas uz grāmatvedību nonāk klienta kartīte, rēķins, PVN likme, apmaksas termiņš, dimensijas un maksājuma statuss. Savukārt atpakaļ var nākt informācija par debitoru atlikumiem vai apmaksas faktu. Šādā modelī svarīga ir ne tikai datu nosūtīšana, bet arī atgriezeniskā saite, kļūdu žurnāli un unikāli identifikatori, lai viens un tas pats dokuments netiktu ieimportēts divreiz.

Datu imports ir vienkāršāks scenārijs. Viena sistēma sagatavo failu, otra to ielasa. Tas var būt Excel, CSV, XML vai cits strukturēts formāts. Šis modelis bieži ir pietiekams, ja dokumenti ir standartizēti un nav vajadzīga nepārtraukta sinhronizācija. Piemēram, mēs varam reizi dienā sagatavot pārdošanas rēķinu failu importam grāmatvedības programmā.

Eksports ir vēl šaurāks gadījums. Sistēma ļauj izņemt datus, bet ne vienmēr nodrošina, ka otra puse tos var ielasīt bez papildu apstrādes. Ja piegādātājs saka, ka “ir eksports uz Excel”, tas vēl nenozīmē, ka savienojums ar grāmatvedību būs praktiski lietojams. Grāmatvedības programmai vajag konkrētu kolonnu secību, datumu formātus, kontējuma loģiku un dokumentu tipus.

Daļēji automatizēts savienojums ir starpvariants. Piemēram, sistēma automātiski sagatavo failu un ievieto to noteiktā mapē vai nosūta uz SFTP, bet imports grāmatvedības programmā tiek palaists manuāli. Vai arī klientu kartītes tiek sinhronizētas automātiski, bet kredītrēķinus apstiprina cilvēks. Šāds modelis bieži ir ļoti saprātīgs, jo samazina roku darbu, bet atstāj kontroli vietās, kur kļūdas izmaksātu dārgi.

Tāpēc ar formulējumu “var pieslēgt” vien nepietiek. Jānoskaidro, vai runa ir par:

  • vienreizēju datu ielādi,
  • regulāru failu apmaiņu,
  • pilnībā automātisku divvirzienu integrāciju,
  • vai procesu, kur daļa soļu paliek manuāli.

Ja strādājat ar e-rēķiniem, PVN likmēm, avansa maksājumiem, kredītrēķiniem vai noliktavas kustībām, atšķirība starp šiem modeļiem kļūst ļoti būtiska. Latvijā svarīgi ir arī tas, ka grāmatvedības uzskaitei un attaisnojuma dokumentiem jābūt korekti noformētiem atbilstoši vietējām prasībām. Ar tehnisku savienojumu vien nepietiek, ja dokumenta saturs vai izsekojamība neatbilst tam, ko pēc tam vajag grāmatvedībā un auditā.

Kādus savienojuma veidus parasti salīdzina?

Visbiežāk salīdzina četrus modeļus, API integrāciju, failu apmaiņu, starpsistēmas un manuālus procesus.

API integrācija parasti ir elastīgākais un modernākais variants. Viena sistēma ar definētiem pieprasījumiem nodod datus otrai sistēmai. Priekšrocības ir ātrums, iespēja validēt datus pirms ieraksta izveides, detalizētas kļūdas un bieži arī drošāka piekļuves kontrole. API ir labs risinājums, ja vajag biežu sinhronizāciju, piemēram, klientu kartītēm, pasūtījumiem, rēķiniem vai maksājumu statusiem. Mīnuss ir tas, ka ieviešana parasti prasa vairāk analīzes, testēšanas un uzturēšanas. Ja kāda no sistēmām maina API versiju, integrācija jāpielāgo.

Failu apmaiņa ir konservatīvāks, bet daudzos gadījumos ļoti praktisks risinājums. Dati tiek nodoti CSV, XML, TXT vai citā formātā, izmantojot koplietotu mapi, SFTP vai citu kanālu. Priekšrocība ir vienkāršība un zemākas sākotnējās izmaksas. Tas labi darbojas, ja dokumentu apjoms ir prognozējams un nav vajadzīga sekundes precizitāte. Mīnusi ir lielāks risks, ka faila struktūra mainīsies, kā arī vājāka kļūdu atgriezeniskā saite. Ja importā kaut kas neizdodas, reizēm jāmeklē konkrētā rinda vai jālabo fails manuāli.

Starpsistēmas jeb middleware ir noderīgas, ja jāslēdz kopā vairāk nekā divas sistēmas vai ja datu transformācijas ir sarežģītas. Piemēram, viena sistēma klientu identificē pēc e-pasta, otra pēc koda, bet grāmatvedība pieprasa atsevišķus dimensiju laukus. Starpsistēma var pārtulkot laukus, validēt vērtības, saglabāt žurnālus un pārvaldīt rindas. Tas ir spēcīgs risinājums augošiem uzņēmumiem, bet tas nozīmē vēl vienu komponenti, ko uzturēt un uzraudzīt.

Manuāli procesi nav jāizslēdz tikai tāpēc, ka tie nav “moderni”. Ja dokumentu ir maz, ja process bieži mainās vai ja katram ierakstam nepieciešama cilvēka pārbaude, manuāls imports vai eksports var būt ekonomiski pareizākais variants. Problēma sākas brīdī, kad manuālais process tiek uzdots kā integrācija. Tad rodas nepamatotas gaidas par ātrumu un kvalitāti.

Izvēloties starp šiem variantiem, jāskatās ne tikai uz tehnoloģiju, bet arī uz procesu. Piemēram, ja mums svarīga ir e-rēķinu apstrāde un dokumentu aprite, failu apmaiņa var būt pilnīgi pietiekama, ja dokumentu struktūra ir stabila. Savukārt, ja vajag bieži apmainīties ar statusiem un notikumiem, piemērotāks būs automatizēts savienojums ar API loģiku.

Kā pārbaudīt, vai konkrētais pieslēgums der jūsu procesam

Lai saprastu, vai konkrēts pieslēgums derēs, nepietiek jautāt, vai “ir integrācija grāmatvedības programmā”. Jāpārbauda četri pamatelementi, dokumentu tipi, datu lauki, sinhronizācijas biežums un kļūdu apstrāde.

Vispirms uzskaitām dokumentu tipus. Vai jāpārsūta tikai pārdošanas rēķini? Vai arī priekšapmaksas rēķini, kredītrēķini, pavadzīmes, kases dokumenti, bankas maksājumi, noliktavas kustības, avansa norēķini? Daudzos projektos tieši kredītrēķini un daļējie maksājumi atklāj, ka sākotnēji plānotais modelis ir par vienkāršu.

Tālāk pārbaudām datu laukus. Ne tikai “klients” un “summa”, bet konkrēti:

  • klienta nosaukums,
  • reģistrācijas numurs,
  • PVN maksātāja numurs,
  • juridiskā adrese,
  • dokumenta numurs,
  • dokumenta datums,
  • apmaksas termiņš,
  • valūta,
  • PVN likme,
  • preču vai pakalpojumu rindas,
  • kontējuma pazīmes,
  • struktūrvienība,
  • projekts vai dimensija,
  • maksājuma veids,
  • pievienotie faili.

Ja kāds no šiem laukiem vienā sistēmā nav obligāts, bet otrā ir obligāts, tas jāatrisina pirms ieviešanas. Pretējā gadījumā importi kritīs vai arī grāmatvedībā parādīsies nepilnīgi ieraksti.

Trešais jautājums ir biežums. Vai dati jāsinhronizē reāllaikā, ik stundu, reizi dienā, vai tikai mēneša slēgumā? Reāllaiks izklausās pievilcīgi, bet ne vienmēr ir vajadzīgs. Ja grāmatvedība dokumentus apstrādā nākamajā dienā, pietiek ar nakts sinhronizāciju. Tas bieži vien samazina ieviešanas sarežģītību un uzturēšanas risku.

Ceturtais ir kļūdu apstrāde. Kas notiek, ja klienta kartītei trūkst PVN numura? Ja dokuments ar tādu pašu numuru jau eksistē? Ja savienojums nav pieejams? Ja grāmatvedības sistēma pieņem dokumenta galveni, bet noraida vienu rindu? Bez skaidras kļūdu loģikas komanda ātri nonāk situācijā, kur neviens nezina, kuri dokumenti ir iegrāmatoti un kuri nav.

Praktiski mēs iesakām prasīt testa scenārijus, nevis tikai funkciju sarakstu. Piemēram:

  • izveidot parastu pārdošanas rēķinu,
  • izveidot kredītrēķinu,
  • importēt klientu ar ārvalstu PVN numuru,
  • apstrādāt dokumentu ar vairākām PVN likmēm,
  • izlabot kļūdainu ierakstu un pārsūtīt to atkārtoti.

Ja jūsu process ietver loģistiku vai piegādes dokumentus, noderīgi ir arī savlaicīgi saprast, kā sistēma sasaista operatīvos datus ar finanšu dokumentiem. Šeit bieži palīdz pasūtījumu un piegāžu datu automatizācija, jo tad var jau sākumā definēt, kuri notikumi rada grāmatvedības dokumentu un kuri ir tikai operatīva informācija.

Kādi jautājumi jāuzdod piegādātājam pirms lēmuma

Pirms lēmuma piegādātājam jāuzdod ļoti konkrēti jautājumi. Jo konkrētāki jautājumi, jo mazāks risks saņemt vispārīgas atbildes.

Par ieviešanu:

  • Kuri dokumentu tipi jau ir atbalstīti, un kuri jāizstrādā papildus?
  • Vai ir gatavs savienojums ar konkrēto grāmatvedības programmu, vai tikai tehniska iespēja integrēties?
  • Kā notiek datu kartēšana starp laukiem?
  • Vai paredzēta testēšanas vide?
  • Kā izskatās pieņemšanas testi un kurš tos apstiprina?
  • Cik lielā mērā mums jāiesaista savs grāmatvedis, IT komanda un procesa īpašnieks?

Par atbildību:

  • Kurš atbild, ja dati nav importēti?
  • Kurš uzrauga sinhronizācijas statusu ikdienā?
  • Vai ir skaidrs robežpunkts starp jūsu sistēmu, grāmatvedības programmu un trešo pušu risinājumiem?
  • Kā tiek fiksētas izmaiņas prasībās pēc projekta sākuma?

Par drošību:

  • Kā notiek autentifikācija, lietotājvārds un parole, API atslēga, OAuth vai cits mehānisms?
  • Vai dati tiek šifrēti pārsūtē un glabāšanā?
  • Kur glabājas integrācijas žurnāli?
  • Cik ilgi tie tiek uzglabāti?
  • Kā tiek ierobežotas piekļuves tiesības?

Par atjauninājumiem:

  • Kas notiek, ja mainās grāmatvedības programmas versija vai API?
  • Vai uzturēšanā ir iekļauta pielāgošana pie standarta atjauninājumiem?
  • Kā tiek paziņotas plānotās izmaiņas?
  • Vai ir versiju kontrole failu formātiem un integrācijas noteikumiem?

Par atbalstu:

  • Kur pieteikt incidentus?
  • Kāds ir reakcijas laiks kritiskām kļūdām?
  • Vai atbalsts palīdz arī datu satura problēmās, vai tikai tehniskās kļūdās?
  • Vai ir pieejams kļūdu žurnāls, ko var pārskatīt arī mūsu komanda?

Ja uzņēmumā ir vairāki procesi, kas skar finanses, piemēram, pasūtījumi, piegādes, noliktava un rēķini, ir vērts domāt nevis par vienu izolētu pieslēgumu, bet par kopējo plūsmu. Šādās situācijās labi strādā procesu integrācija starp sistēmām, jo tad varam vienā arhitektūrā sakārtot gan datu avotus, gan atbildības robežas.

Kur slēpjas izmaksas un riski pēc integrācijas palaišanas

Lielākā daļa uzņēmumu salīdzina sākotnējās ieviešanas izmaksas, bet mazāk novērtē to, kas notiek pēc palaišanas. Tieši tur bieži slēpjas lielākie pārsteigumi.

Pirmais ir uzturēšana. Pat ja integrācija šodien strādā, sistēmas mainās. Mainās lauku struktūra, dokumentu tipi, autentifikācijas prasības, PVN loģika, biznesa process. Ja nav vienošanās, kurš uztur savienojumu un kā tiek apmaksātas izmaiņas, katrs atjauninājums var kļūt par atsevišķu projektu.

Otrais ir izmaiņu pieprasījumi. Sākumā uzņēmums grib pārsūtīt tikai rēķinus. Pēc trim mēnešiem vajag arī kredītrēķinus, pēc tam priekšapmaksu, pēc tam dimensijas pa projektiem. Tas nav nekas neparasts. Tāpēc jāvērtē, cik viegli risinājumu var paplašināt bez pilnīgas pārbūves.

Trešais ir dīkstāves risks. Ja savienojums apstājas mēneša slēguma dienā, sekas ir daudz lielākas nekā parastā otrdienā. Tāpēc svarīgi zināt, vai ir rindas mehānisms, atkārtots mēģinājums, paziņojumi par kļūdām un iespēja importu palaist atkārtoti bez dubultiem ierakstiem.

Ceturtais ir datu kvalitāte. Sliktas kvalitātes dati ir biežāks iemesls problēmām nekā pati tehnoloģija. Ja klientu kartītēs nav vienotu kodu, ja PVN likmes tiek ievadītas brīvā tekstā, ja produktu nosaukumi dublējas, integrācija tikai ātrāk pārvietos nekārtību no vienas sistēmas uz otru. Pirms palaišanas jāsakārto pamatdati un jāvienojas par to īpašniekiem.

Piektais ir auditējamība. Grāmatvedībā ir svarīgi saprast, no kurienes konkrēts dokuments radies, kurš to izveidojis, kad tas nosūtīts un vai pēc tam mainīts. Latvijā tas ir īpaši svarīgi, jo attaisnojuma dokumentu aprite un uzskaite jāspēj pamatot ne tikai iekšēji, bet arī pārbaudes gadījumā. ES līmenī principi ir līdzīgi, bet konkrētas prasības dokumentu noformēšanai un glabāšanai praksē tiek piemērotas pēc nacionālā regulējuma un VID prasībām.

Tāpēc lētākais sākuma risinājums ne vienmēr ir lētākais kopējās īpašumtiesību izmaksās. Ja katra kļūda jālabo manuāli, ja nav žurnālu un ja katra procesa izmaiņa prasa programmēšanu, sākotnējais ietaupījums ātri izkūst.

Kā salīdzināt variantus, ja atbilde nav vienkārši jā vai nē

Bieži atbilde nav vienkārši “jā, var” vai “nē, nevar”. Pareizāk ir salīdzināt variantus pēc vienota ietvara un izvēlēties to modeli, kas vislabāk der jūsu procesam šobrīd un tuvākajā nākotnē.

Mēs iesakām vērtēt vismaz šādus kritērijus.

Pirmais, procesu atbilstība. Vai risinājums atbalsta tieši tos dokumentus un scenārijus, kas jums ir svarīgi? Nevis teorētiski, bet praksē.

Otrais, datu pilnīgums. Vai tiek nodoti visi nepieciešamie lauki, ieskaitot dimensijas, PVN informāciju, maksājumu nosacījumus un dokumentu pielikumus?

Trešais, automatizācijas līmenis. Cik daudz darba paliek cilvēkiem? Vai manuālie soļi ir pieņemami un kontrolējami?

Ceturtais, kļūdu pārvaldība. Vai ir redzami statusi, kļūdu paziņojumi, atkārtotas apstrādes iespējas un dubultu ierakstu kontrole?

Piektais, ieviešanas sarežģītība. Cik ilgi un ar cik lielu iesaisti risinājumu var palaist? Vai ir vajadzīga abu piegādātāju līdzdalība?

Sestais, uzturēšanas slodze. Cik bieži būs vajadzīgas izmaiņas, un cik viegli tās ieviest?

Septītais, drošība un atbilstība. Vai risinājums atbilst jūsu iekšējām prasībām par piekļuvi, žurnāliem un datu aizsardzību?

Astotais, mērogojamība. Vai pēc gada varēsiet pievienot vēl vienu dokumenta tipu, juridisko vienību vai sistēmu, nepārbūvējot visu no jauna?

Vienkāršākais praktiskais veids ir izveidot salīdzinājuma tabulu ar trim vai četriem reāliem variantiem. Piemēram:

  • manuāls CSV eksports un imports,
  • automatizēta failu apmaiņa,
  • tieša API integrācija,
  • starpsistēmas risinājums.

Katram variantam piešķiram vērtējumu pēc iepriekš minētajiem kritērijiem un pierakstām pieņēmumus. Ļoti svarīgi ir norādīt arī to, kas nav iekļauts. Piemēram, “atbalsta tikai pārdošanas rēķinus”, “nav kredītrēķinu”, “maksājumu statuss netiek sinhronizēts”, “kļūdu paziņojumi tikai e-pastā”. Tieši šīs piezīmes vēlāk pasargā no nepareizām gaidām.

Ja jautājums ir, vai var pieslēgt grāmatvedības programmai, mūsu pieredzē gandrīz vienmēr atbilde ir “jā, kādā formā var”. Taču pareizais lēmums ir nevis izvēlēties maksimāli sarežģītu integrāciju, bet gan tādu savienojuma modeli, kas atbilst jūsu dokumentiem, cilvēku kapacitātei, kontroles prasībām un izaugsmes plāniem. Labs pieslēgums nav tas, kurš izklausās iespaidīgi, bet tas, kurš ikdienā samazina kļūdas, paātrina darbu un dod skaidru atbildību par katru datu soli.