E-rēķinu integrācija uzņēmumā: e-adrese, operators vai grāmatvedības sistēmas savienojums

E-rēķinu integrāciju izvēlieties pēc saņēmēju prasībām, manuālā darba apjoma un vajadzīgās kontroles, nevis tikai pēc nosūtīšanas cenas. E-adrese ir oficiālās saziņas un dokumentu piegādes vide; e-rēķinu operators piedāvā dokumentu apmaiņas pakalpojumu; grāmatvedības sistēmas savienojums nodrošina datu kustību uzskaites procesā. Tie nav obligāti savstarpēji izslēdzoši varianti: sistēma var būt savienota ar operatoru, kurš nodrošina tālāku piegādi.

Ja dokumentu ir maz un to apriti var droši uzraudzīt atbildīgais darbinieks, var pietikt ar manuālu apstrādi izvēlētajā kanālā. Ja rēķinu dati tiek pārrakstīti, pazūd piegādes statuss vai saņēmējiem ir atšķirīgas prasības, jāvērtē sistēmu savienojums un, iespējams, operatora pakalpojums. Izvēles rezultātam jābūt pārbaudāmai darba plūsmai no rēķina izveides līdz saņemšanai un uzskaitei, nevis tikai iespējai augšupielādēt failu.

Strukturēts e-rēķins nav PDF pielikums

Strukturēts e-rēķins ir elektroniski sagatavots rēķins ar datiem saskaņotā, mašīnlasāmā struktūrā, kas ļauj tos automātiski apstrādāt. Parasts PDF rēķins e-pastā nav strukturēts e-rēķins; arī elektronisks paraksts pats par sevi nepārvērš PDF par strukturētu dokumentu.

Jāatšķir trīs lietas: rēķina dati, to tehniskais formāts un piegādes kanāls. XML fails pats par sevi vēl nepierāda atbilstību: jāpārbauda gan paredzētā struktūra, gan datu saturs un piemērojamie validācijas noteikumi.

EN 16931 apraksta e-rēķina semantisko datu modeli. Peppol BIS Billing 3.0 ir konkrētāka e-rēķinu apmaiņas specifikācija ar saviem noteikumiem. Peppol dokumentācija ir tehnisks atskaites punkts, ja izvēlētais risinājums izmanto šo specifikāciju, nevis pierādījums, ka visi Latvijas e-rēķini jānosūta Peppol tīklā.

Uzņēmumam jāzina ne tikai tas, vai programma eksportē XML, bet arī tas, vai saņēmējs šo dokumentu spēj pieņemt un apstrādāt bez datu zuduma.

E-rēķinu integrācija: trīs kombinējami līmeņi

Salīdzinājumā nodaliet dokumenta pārvadāšanu no tā apstrādes uzņēmumā. Citādi var nopirkt ērtu nosūtīšanu, bet atstāt visu grāmatveža manuālo darbu neskartu.

E-adresi var izmantot arī automatizētā risinājumā, ja izvēlētais savienojums to atbalsta. Portāla manuāla lietošana un sistēmu integrācija nav viens un tas pats. E-adreses iespējas un piekļuves kārtību pārbaudiet oficiālajā portālā Latvija.gov.lv.

Operatora piedāvājumā savukārt neuzskatiet formātu pārveidošanu, arhīvu vai visu partneru sasniedzamību par pašsaprotamu. Šīm funkcijām jābūt skaidri aprakstītām pakalpojumā.

Ienākošo un izejošo rēķinu vajadzības vērtējiet atsevišķi. Programma var labi nosūtīt rēķinus, bet saņemtos tikai parādīt sarakstā, nepārnesot tos uz grāmatvedības ierakstiem. Demonstrācijā prasiet parādīt abas plūsmas līdz uzņēmumam vajadzīgajam rezultātam, nevis tikai veiksmīgu faila nosūtīšanu.

Vispirms noskaidrojiet pienākumu, pēc tam izvēlieties kanālu

Šis ir risinājuma izvēles ceļvedis, nevis aktuālo ieviešanas termiņu kalendārs. Avotu aktuālā redakcija un pakalpojumu funkcijas šeit nav pārbaudītas reāllaikā. Pirms ieviešanas pārbaudiet Grāmatvedības likuma spēkā esošo redakciju un pārejas noteikumus, kā arī VID informāciju par e-rēķiniem.

Darījuma partnera statuss, darījuma veids un pārejas noteikumi var ietekmēt piemērojamo pienākumu. Par konkrēta darījuma prasībām konsultējieties ar grāmatvedi vai nodokļu konsultantu; tās nevajadzētu noteikt pēc programmatūras reklāmas apraksta.

Pirms tehniskā uzdevuma sagatavošanas atbildiet uz trim jautājumiem:

•          Kuriem uzņēmuma dokumentiem un darījumu partneriem piemērojama strukturēta e-rēķina prasība?
•          Kāds formāts un piegādes ceļš ir pieņemams konkrētajam saņēmējam?
•          Vai ir piemērojams atsevišķs pienākums nodot rēķinu datus VID, un kurš risinājuma dalībnieks to izpilda?

Nosūtīšana klientam un datu nodošana VID ir atšķirīgi procesa uzdevumi. Neuzskatiet, ka viena darbība automātiski izpilda otru. Ja piegādātājs sola abus, prasiet demonstrēt abu darbību statusus un kļūdu paziņojumus. Saglabājiet arī vienošanos par to, kurš pārbauda normatīvo izmaiņu ietekmi uz konfigurāciju.

Sagatavojiet salīdzināmu uzdevumu piegādātājiem

Aprakstiet pašreizējo rēķinu apriti vienā darba dokumentā. Norādiet izrakstīšanas sistēmu, uzskaites sistēmu, saņēmēju grupas, izmantotos kanālus, dokumentu apjomu un tā svārstības. Iekļaujiet arī saņemtos rēķinus un vietas, kur cilvēks pašlaik pārraksta vai labo datus.

Nav universāla rēķinu skaita, no kura integrācija obligāti atmaksājas. Daži sarežģīti rēķini ar daudzām pozīcijām var prasīt vairāk darba nekā liels vienkāršu dokumentu kopums. Tādēļ pie apjoma pierakstiet apstrādes laiku, biežākos izņēmumus un kavējumu sekas.

Pievienojiet reprezentatīvus, droši anonimizētus dokumentu paraugus: parastu rēķinu, kredītrēķinu un jūsu darbībai būtiskos nestandarta gadījumus. Ja izmantojat pielikumus, valūtas vai atsauces uz pasūtījumiem, iekļaujiet arī tos. Vienāds paraugu komplekts palīdz salīdzināt piedāvājumus pēc faktiskas darbības, nevis funkciju nosaukumiem.

Ieviešana sešos pārbaudāmos soļos

1. Nosakiet datu avotu un lauku atbilstību

Vienojieties, kura sistēma ir galvenais avots rēķina numuram, partnera datiem, pozīcijām, summām un apmaksas termiņam. Ja rēķins rodas pārdošanas sistēmā, bet uzskaite notiek citur, skaidri nosakiet, kur drīkst veikt labojumus un kā tie nonāk tālāk.

Izveidojiet lauku atbilstības tabulu: avota lauks, mērķa lauks, pārveidošanas noteikums un pārbaudes veids. Īpaši pārbaudiet PVN kategorijas, noapaļošanu, mērvienības, atlaides un atsauces uz līgumu vai pasūtījumu. Ne visi šie lauki ir universāli obligāti, taču konkrēts saņēmējs tos var prasīt savam procesam.

Reģistrācijas numuru neuzskatiet par automātisku aizstājēju konkrētā tīkla saņēmēja identifikatoram. Piegādes adresēšanai vajadzīgos datus pārbaudiet atbilstoši izvēlētā kanāla prasībām. Grāmatvedim jāpārbauda datu ekonomiskā nozīme, bet integrācijas izstrādātājam — to tehniskā pārnese.

2. Vienojieties par formātu un savienojumu

Pierakstiet atbalstīto formātu, tā versiju, validācijas noteikumus, pielikumu ierobežojumus un autentifikācijas kārtību. Vienošanās jāattiecina uz visu ceļu līdz saņēmējam, nevis tikai eksportu no pirmās programmas.

API nav obligāts katrā situācijā. Kontrolēta failu apmaiņa var būt pietiekama, ja pieļaujams periodisks imports un ir skaidra apstrādes kārtība. API ir vērts vērtēt, ja vajadzīga regulāra automatizēta apmaiņa un statusu saņemšana, taču arī tas prasa kļūdu apstrādi un uzturēšanu.

Ja operators pārveido formātu, pārbaudiet, vai saglabājas visas uzņēmumam un saņēmējam būtiskās vērtības. Veiksmīga pārveidošana nav tikai tehniski atverams fails. Vienojieties arī par paziņošanu pirms formātu vai saskarņu izmaiņām un par atkārtotu pārbaudi pēc atjauninājumiem.

3. Atdaliet piegādes un grāmatvedības statusus

Iekšējā modelī var būt secība: izveidots → validēts → nodots kanālam → piegāde apstiprināta. Saņēmēja apstrādes statusu pievienojiet tikai tad, ja konkrētais risinājums to tiešām sniedz. Statusi «iegrāmatots» un «apmaksāts» jāsaņem no sistēmām, kurās šie notikumi tiek uzskaitīti.

Sekmīga API atbilde var nozīmēt tikai pieprasījuma pieņemšanu. Tā ne vienmēr apliecina dokumenta piegādi, saņēmēja piekrišanu vai iegrāmatošanu. Katram statusam aprakstiet tā avotu, nozīmi un laiku, kad jārīkojas, ja nākamais notikums nav saņemts. Darbiniekam jāspēj atrast konkrētu rēķinu un saprast tā pašreizējo stāvokli bez piekļuves izstrādātāja tehniskajiem žurnāliem.

4. Novērsiet atkārtotu apstrādi

Noildze var rasties pēc tam, kad otra sistēma rēķinu jau saņēmusi. Atkārtota nosūtīšana tādēļ nedrīkst automātiski radīt otru rēķinu vai grāmatojumu. Izmantojiet idempotences mehānismu un saglabājiet sasaisti starp uzņēmuma dokumenta identifikatoru, apmaiņas identifikatoru un ārējās sistēmas atbildi.

Rēķina numurs viens pats ne vienmēr ir pietiekams dublikāta noteikšanai, īpaši ienākošajā plūsmā ar dažādiem piegādātājiem. Dublikāta kritēriji jāizvēlas atbilstoši dokumentu numerācijai un biznesa noteikumiem.

Labojumam vai kredītrēķinam vajadzīga paredzēta saikne ar sākotnējo dokumentu un atsevišķa apstrāde, nevis sākotnējā ieraksta klusa pārrakstīšana. Pārbaudē atkārtojiet gan vienu nosūtīšanas pieprasījumu, gan viena dokumenta saņemšanu pa atkārtotu piegādes ceļu.

5. Izveidojiet izņēmumu darba rindu

Atšķiriet datu kļūdu, īslaicīgu savienojuma kļūmi un neskaidru piegādes rezultātu. Trūkstošu obligāto lauku neatrisinās atkārtota sūtīšana. Savukārt neskaidra rezultāta gadījumā pirms manuālas pārsūtīšanas jāpārbauda, vai dokuments jau nav pieņemts.

Katram izņēmumam jābūt īpašniekam, rīcībai un ierakstam par atrisinājumu. Nosakiet arī aizvietotāju prombūtnes laikā. Rezerves process nedrīkst radīt paralēlu, neuzskaitītu rēķinu apriti e-pastā. Ja pieļaujama manuāla nosūtīšana, tās rezultāts jāatspoguļo kopējā uzskaitē, lai automatizācija vēlāk neizsūtītu dokumentu atkārtoti.

6. Pārbaudiet visu procesu, nevis tikai eksportu

Testos iekļaujiet derīgu dokumentu, noraidītu dokumentu, trūkstošu saņēmēja prasītu atsauci, kredītrēķinu, pielikumu, atkārtotu pieprasījumu un savienojuma noildzi. Grāmatvedim jāpārbauda arī summas, PVN piemērošanas atspoguļojums un noapaļošana. Tehniska validācija neaizstāj darījuma grāmatvedisku izvērtējumu.

Katram testam iepriekš pierakstiet sagaidāmo rezultātu: kas parādās nosūtītāja sistēmā, ko saņem otra puse un kāds ieraksts rodas uzskaitē. Ja pieejama piegādātāja testa vide, izmantojiet to; ja nav, drošu izmēģinājuma kārtību saskaņojiet ar iesaistītajiem.

Atsevišķi pārbaudiet operatora vai kanāla nepieejamību un atjaunošanos. Pēc traucējuma jāspēj salīdzināt neapstrādātos dokumentus, nevis vienkārši palaist visu plūsmu no sākuma. Testa rezultātā jābūt pierādāmai dokumentu un statusu sakritībai abās sistēmās.

Ierobežojumi, drošība un dokumentu glabāšana

Integrācija neizlabo nekvalitatīvus pamatdatus un nepārvērš katru saņemtu rēķinu par automātiski apstiprināmu izdevumu. Ja uzņēmumā vajadzīga darījuma pārbaude vai izdevumu saskaņošana, saglabājiet šo kontroli arī pēc tehniski veiksmīga importa. Maksājuma sagatavošanu un apstiprināšanu projektējiet kā atsevišķu atbildības posmu.

Piešķiriet sistēmas kontam tikai nepieciešamās tiesības. API piekļuves datus glabājiet aizsargāti, paredziet to nomaiņu un nepieļaujiet kopīga darbinieka konta izmantošanu visai integrācijai. Žurnālos nevajadzētu bez vajadzības kopēt pilnu rēķina saturu vai piekļuves noslēpumus.

Rēķinos var būt personas dati. Ja tie tiek apstrādāti, izvērtējiet pušu lomas, piekļuves, apstrādes nosacījumus un aizsardzības pasākumus atbilstoši Vispārīgajai datu aizsardzības regulai. Lomas nosaka faktiskā apstrāde, nevis tikai piegādātāja nosaukums.

Glabājiet nosūtīto vai saņemto strukturēto dokumentu, nepieciešamos pielikumus un apstrādes pierādījumus; vizualizāciju saglabājiet, ja tā vajadzīga darbam. Glabāšanas termiņus nosakiet pēc piemērojamajām prasībām. Operatora portālu neuzskatiet par uzņēmuma arhīvu bez skaidras vienošanās par termiņiem, pieejamību un eksportu pēc līguma beigām. Rezerves kopija un ilgtermiņa arhīvs nav viens un tas pats.

Salīdziniet kopējās izmaksas un atbildības robežas

Piedāvājumus salīdziniet vienā izvēlētā periodā, nodalot ieviešanu, abonēšanu, maksu par dokumentiem, uzturēšanu un paliekošo manuālo darbu. Datu eksporta un pakalpojuma maiņas izmaksas parādiet atsevišķi. Lēta nosūtīšana var nebūt lēta aprite, ja darbinieks pēc tam labo katru importu.

Manuālā darba novērtēšanai izmantojiet pašu procesa novērojumus: dokumentu skaitu, faktisko apstrādes laiku un izņēmumu biežumu. Neaizstājiet tos ar piegādātāja vispārīgu ietaupījuma solījumu. Aprēķinā atstājiet arī laiku uzraudzībai, atbalsta saziņai un izmaiņu pārbaudēm.

Līgumā vai tehniskajā uzdevumā nosakiet, kurš uztur lauku atbilstību, reaģē uz kļūdām un pielāgo risinājumu specifikācijas izmaiņām. Pieprasiet konkrētu atbalsta kārtību: kam pieteikt problēmu, kādi dati vajadzīgi izmeklēšanai un kurš koordinē sadarbību starp operatoru un grāmatvedības programmas piegādātāju. Uzņēmuma grāmatvedim nevajadzētu palikt par vienīgo starpnieku tehniskā strīdā starp diviem pakalpojumiem.

Kā pieņemt lēmumu pēc izmēģinājuma

Sāciet ar ierobežotu, bet reprezentatīvu dokumentu un partneru kopu. Tā nav tikai vienkāršāko rēķinu atlase: izmēģinājumam jāietver arī uzņēmumam būtiskie izņēmumi. Pirms sākuma vienojieties, kāds rezultāts ļauj paplašināt lietošanu un kādos gadījumos plūsma jāaptur.

Automātiski apstrādāto dokumentu īpatsvarā skaitiet tikai dokumentus, kas sasnieguši iepriekš definēto gala statusu bez manuāla datu labojuma. Izejošam rēķinam tas var būt apstiprināta piegāde, ienākošam — imports un pārbaude uzskaites sistēmā. Abas plūsmas mēriet atsevišķi.

Vērojiet arī apstrādes laiku, noraidījumu iemeslus, iestrēgušo dokumentu vecumu un manuālai labošanai patērēto laiku. Labs kopējais sekmju rādītājs nedrīkst noslēpt dažus ilgstoši nepiegādātus rēķinus.

Pirms plašākas ieviešanas pārbaudiet:

•          Vai katru dokumentu var izsekot no avota līdz paredzētajam gala statusam?
•          Vai atkārtojums nerada dublikātu un neskaidrs statuss ir atrisināms?
•          Vai saņēmējs saņem vajadzīgos datus, nevis tikai tehniski derīgu failu?
•          Vai kļūmes laikā ir atbildīgais un kontrolēts rezerves process?
•          Vai uzņēmums var eksportēt dokumentus un nepieciešamos apstrādes pierādījumus?

Ja atbilde uz kādu jautājumu nav skaidra, precizējiet risinājumu pirms apjoma palielināšanas. Pieņemšanas kritērijiem jāapliecina pārvaldāma aprite, nevis vienkārši tas, ka savienojums vienreiz nostrādāja.

Nākamais solis

Pirms prasāt cenu, sagatavojiet dokumentu paraugus, saņēmēju prasības un abu rēķinu plūsmu shēmu. Ar šo materiālu var pamatoti izlemt, vai pietiek sakārtot esošās programmas iespējas, vajadzīgs operators vai jāizstrādā atsevišķs savienojums.

Ja jāizvēlas savienojuma veids, nākamais lasāmais raksts ir «Kad uzņēmumam vajadzīga API integrācija un kad pietiek ar vienkāršāku datu apmaiņu». Atkārtotas apstrādes tehniskajam projektam noder «Idempotence integrācijās: kā nepieļaut dubultus rēķinus un pasūtījumus».