Katrs pasūtījums vienā laika līnijā, no saņemšanas līdz apmaksātam rēķinam.
Procesi no pasūtījuma līdz apmaksai, no iepirkuma līdz maksājumam un no pakalpojuma pieteikuma līdz rēķinam iet caur ERP, CRM, e-komercijas, noliktavas, transporta un finanšu sistēmām. Mēs tās savienojam ar dokumentētām API un notikumiem, katram pasūtījumam visās šajās sistēmās dodam vienu statusu, un katru izņēmumu nosūtām aģentam, kas sagatavo risinājumu, ko apstiprina cilvēks.
Organizācijām, kas pārdod, pērk un izraksta rēķinus vairākās ES dalībvalstīs, katrā ar savām sistēmām, pārvadātājiem un e-rēķinu noteikumiem.
03Vienas laika līnijas veidošana katram pasūtījumamSistēma
04Konteksta savākšana un priekšlikumsMI aģents
05Apstiprināšana sliekšņu robežāsCilvēks
06Rēķins, salīdzināšana un norēķinsSistēma
07Plūsmas pārskats un cēloņu novēršanaCilvēks
Pasūtījums, pirkuma pasūtījums vai pakalpojuma pieteikums tiek reģistrēts vienreiz savā primārajā sistēmā un caur dokumentētām API un notikumiem nodots pārējām sistēmām. Statusa notikumi veido vienu laika līniju katram pasūtījumam. Ja kāds solis neizdodas vai iziet ārpus pielaides, aģents savāc kontekstu un ierosina risinājumu, ko cilvēks apstiprina, pirms tas tiek izpildīts primārajā sistēmā. Rēķini tiek apmainīti un salīdzināti kā strukturēti e-rēķini, un procesu īpašnieki pārskata plūsmu un saskarņu stāvokli.
Pirms un pēc
Kas mainās ikdienas darbā
Šodien
Ar sistēmu
Šodien
Šodien: Atkārtota ievade katrā nodošanā
Pasūtījumu, kas saņemts e-veikalā vai no pārdošanas komandas, ERP sistēmā ievada vēlreiz, un piegādes un rēķina datus ar roku pārkopē noliktavas, transporta un finanšu sistēmās.
Ar sistēmu
Ar sistēmu: Ievadīts vienreiz, izmantots visur
Katrs pasūtījums, piegāde un rēķins tiek izveidots sistēmā, kurai tas pieder, un publicēts kā notikums. Citas sistēmas to abonē, nevis pārraksta.
Šodien
Šodien: Vakardienas statuss
Nakts pakešsaskarņu dēļ klientu apkalpošana, plānošana un finanses redz katra savu, novecojušu tā paša pasūtījuma stāvokli. Klients, kas jautā, kur ir piegāde, saņem atzvanu vēlāk.
Ar sistēmu
Ar sistēmu: Viens aktuāls statuss
Katram pasūtījumam vai pieteikumam ir viena laika līnija, kas veidota no visu sistēmu notikumiem, caur kurām tas iet. Klientu apkalpošana, plānošana un finanses redz tos pašus faktus, un tāpat arī apkalpošanas asistents, kas atbild uz statusa jautājumiem.
Šodien
Šodien: Izņēmumi e-pasta kastēs
Krājumu iztrūkumus, cenu neatbilstības, neizdevušās piegādes un noraidītus e-rēķinus risina e-pastā un izklājlapās, un vēlāk neviens nevar pateikt, kurš ko izlēma.
Ar sistēmu
Ar sistēmu: Izņēmumi pienāk ar priekšlikumu
Aģents savāc datus, kas ir aiz katra izņēmuma, un ierosina risinājumu. Cilvēks vienā izņēmumu darbvietā to apstiprina, labo vai noraida, un lēmums tiek reģistrēts.
Šodien
Šodien: Pamatdati, kas nesakrīt
Viens un tas pats klients, piegādātājs, produkts vai cena ir vairākās sistēmās ar atšķirīgām vērtībām, un neviens neatbild par to, kura ir pareizā.
Ar sistēmu
Ar sistēmu: Viens īpašnieks katram datu objektam
Klientiem, piegādātājiem, produktiem un cenām katram ir saskaņota primārā sistēma un nosaukts īpašnieks. Par dublikātiem un konfliktiem ziņo šim īpašniekam, nevis klusi labo tālāk procesā.
Šodien
Šodien: Katra izmaiņa pievieno saskarni
Jauns pārdošanas kanāls, tirdzniecības platforma vai juridiskā persona nozīmē vēl vienu tiešo savienojumu. Valstu e-rēķinu prasības katram procesam pievieno vēl strukturētu formātu un tīklu.
Ar sistēmu
Ar sistēmu: Jauni savienojumi izmanto tos pašus līgumus
Jauns kanāls, juridiskā persona vai e-rēķinu tīkls vienreiz pievienojas dokumentētām API un notikumiem, nevis katrai sistēmai atsevišķi.
Darba plūsma
Kā darbojas darba plūsma
Ja dati ir tīri, galvenajā ceļā nav vajadzīgs manuāls darbs. Ja pasūtījums, piegāde vai rēķins novirzās, izņēmumu cikls to nogādā pie cilvēka ar pierādījumiem un priekšlikumu, un apstiprinātais labojums atgriežas caur to pašu integrācijas slāni.
Ilustratīva darba plūsma
7 soļi · 1 cilvēka kontrolpunkts
Apzīmējumi
Sistēma
MI aģents
Cilvēks
Cilvēka kontrolpunkts
Izņēmumu ceļš
Savienoti procesi: ilustratīva darba plūsma ar izņēmumu ciklu
Lasīt diagrammu kā tekstu
Galvenais ceļš ved no biznesa notikuma vienreizējas reģistrēšanas primārajā sistēmā caur tā nodošanu citām sistēmām ar API un notikumiem un vienas laika līnijas veidošanu katram pasūtījumam līdz rēķinam, salīdzināšanai un norēķinam. Tas noslēdzas ar to, ka procesu īpašnieki pārskata plūsmu un novērš izņēmumu cēloņus.
Ja kāds solis neizdodas, kavējas vai iziet ārpus pielaides, izņēmums pēc laika līnijas soļa atstāj galveno ceļu. Aģents savāc kontekstu un ierosina risinājumu, un cilvēks to apstiprina, labo vai noraida. Apstiprinātā darbība tiek izpildīta primārajā sistēmā un kā jauns notikums atgriežas nodošanas solī.
Apstiprināšanas solis ir cilvēka kontrolpunkts: bez cilvēka netiek veikts neviens finanšu grāmatojums, cenas vai kredītlimita izmaiņa un netiek uzņemtas saistības pret klientu.
01
1. solis: Notikuma reģistrēšana vienreizSistēma
Pārdošanas pasūtījums no e-veikala, tirdzniecības platformas, EDI vai pārdošanas komandas, pirkuma pasūtījums vai pakalpojuma pieteikums tiek izveidots sistēmā, kurai tas pieder. Šī sistēma publicē biznesa notikumu CloudEvents formātā, kas aprakstīts AsyncAPI līgumā. Papīra un PDF pasūtījumi un piegādātāju rēķini vispirms iziet caur inteliģentu dokumentu apstrādi.
02
2. solis: Nodošana caur API un notikumiemSistēma
Integrācijas slānis notikumu nogādā noliktavas, transporta, finanšu un CRM sistēmām caur to dokumentētajām API (OpenAPI). Saņēmēji ir idempotenti, tāpēc atkārtots ziņojums nekad neizveido otru sūtījumu vai rēķinu, un ziņojumi, ko nevar piegādāt, gaida kļūdu rindā atkārtotai nosūtīšanai.
03
3. solis: Vienas laika līnijas veidošana katram pasūtījumamSistēma
Statusa notikumi no visām sistēmām (apstiprināts, savākts, nosūtīts, piegādāts, izrakstīts rēķins, apmaksāts) pēc biznesa atsauces tiek apvienoti vienā laika līnijā. Kontrolpunktu un pielaides noteikumi rada izņēmumu, ja kāds solis neizdodas, kavējas vai nesakrīt: krājumu iztrūkums, cena ārpus saskaņotās pielaides, neizdevusies piegāde, noraidīts e-rēķins.
04
4. solis: Konteksta savākšana un priekšlikumsMI aģents
Katram izņēmumam aģents no iesaistītajām sistēmām nolasa to, kas tam vajadzīgs: pasūtījumu, krājumu atlikumus, cenu vienošanos, pārvadātāja statusu un klienta noteikumus. Tas ierosina risinājumu ar pamatojumu un izmantotajiem datiem, piemēram, aizvietojošu preci, labotu cenu, pārplānotu piegādi vai labotu rēķinu.
Izņēmumu ceļš: Solis neizdevās vai ir ārpus pielaides
05
5. solis: Apstiprināšana sliekšņu robežāsCilvēks
Klientu apkalpošanas, loģistikas vai finanšu darbinieks izņēmumu darbvietā redz izņēmumu, pierādījumus un priekšlikumu un to apstiprina, labo vai noraida. Apstiprinātā darbība tiek izpildīta caur primārās sistēmas API, un šī sistēma izmaiņu publicē kā jaunu notikumu.
Izņēmumu ceļš: Solis neizdevās vai ir ārpus pielaides· Atgriežas pie 2. soļa
Cilvēka kontrolpunkts
Aģenti nekad bez apstiprinājuma negrāmato finanšu darījumus, nemaina cenas vai kredītlimitus un neuzņemas saistības pret klientu. Sliekšņi katram darbības veidam nosaka, kurš apstiprina, un katrs priekšlikums un lēmums tiek reģistrēts.
06
6. solis: Rēķins, salīdzināšana un norēķinsSistēma
Izejošie rēķini no ERP iziet kā strukturēti e-rēķini (Peppol BIS Billing 3.0, EN 16931) caur piekļuves punktu. Ienākošos piegādātāju rēķinus salīdzina ar pirkuma pasūtījumiem un preču saņemšanu, un maksājuma statuss no bankas vai maksājumu pakalpojumu sniedzēja noslēdz laika līniju.
07
7. solis: Plūsmas pārskats un cēloņu novēršanaCilvēks
Procesu īpašnieki un integrāciju komanda noteiktā ritmā pārskata izņēmumus pa iemesliem, saskarņu kļūmes un pamatdatu konfliktus. Viņi novērš cēloni tur, kur tas atrodas, pamatdatu ierakstā, pielaides noteikumā vai datu atbilstības shēmā, nevis atkal risina to pašu izņēmumu.
Komponenti
Ko mēs izveidotu
01
Notikumu vadīts integrācijas slānis
Uz līgumiem balstītas API un notikumi starp ERP, CRM, e-komerciju, noliktavu, transportu un finansēm, aprakstīti OpenAPI un AsyncAPI ar CloudEvents formātu, Jūsu esošajā integrācijas platformā vai izveidoti mākoņvidē.
Saskaņota primārā sistēma un īpašnieks katram datu objektam, klientu, piegādātāju un produktu salīdzināšanas noteikumi un pārskati par dublikātiem un konfliktiem to īpašniekiem.
Serviss, kas notikumus apvieno vienā laika līnijā katram pasūtījumam vai pieteikumam, piemēro kontrolpunktu un pielaides noteikumus un rāda plūsmu un izņēmumus procesu īpašniekiem.
Izņēmumu rinda ar savākto kontekstu un aģenta priekšlikumu, ar apstiprināšanas, labošanas un noraidīšanas darbībām un apstiprināšanas sliekšņiem katram darbības veidam, kas tiek piemēroti vietā, kur darbība tiek izpildīta.
Peppol BIS Billing 3.0 un EN 16931 rēķini UBL formātā, nosūtīti un saņemti caur piekļuves punktu, pārbaudīti pirms nosūtīšanas, ar noraidīto rēķinu novirzīšanu uz izņēmumu darbvietu.
Katras saskarnes stāvokļa uzraudzība un brīdinājumi, darbības rokasgrāmatas ekspluatācijas komandai un kontrolēta neizdevušos ziņojumu atkārtota nosūtīšana, izvietota ar infrastruktūru kā kodu Jūsu mākoņa vidē.
Pakalpojumu pieteikumi un izbraukuma darbu atskaites
Pārvadātāju izsekošanas un piegādes notikumi
Peppol e-rēķini un statusa atbildes
Bankas izraksti un maksājumu paziņojumi
Risinājuma kodols
Savienoti procesi
Sistēmas, ar kurām tas strādā
SAP S/4HANA pārdošana, iepirkumi un finansesPlatformaSAP
Salesforce Sales, Service un Commerce CloudPlatformaSalesforce
Odoo pārdošana, krājumi, iepirkumi un grāmatvedībaPlatformaOdoo
E-komercijas platformas, tirdzniecības platformas un pārvadātāju API
Noliktavas un transporta vadības sistēmas
Peppol piekļuves punkts, bankas un maksājumu pakalpojumu sniedzēji
Produktu informācijas pārvaldība un datu platforma
Kontroles
Iebūvētās kontroles
Piekļuves robežas
Katra integrācija un aģents katrā sistēmā darbojas ar savu servisa identitāti, kas ierobežota ar vajadzīgajām API operācijām. Aģents var lasīt datus vairākās sistēmās, lai savāktu kontekstu, bet rakstīt tas var tikai caur īsu apstiprinātu darbību sarakstu, ko izpilda primārās sistēmas API, un nekad tieši datubāzē.
Cilvēka pārbaude
Apstiprināšanas sliekšņus katram darbības veidam nosaka kopā ar procesa īpašnieku: ko aģents drīkst tikai ierosināt, ko apstiprina komandas loceklis un kam vajadzīgs otrs apstiprinātājs. Finanšu grāmatojumi, cenu un kredītlimitu izmaiņas un saistības pret klientiem vienmēr gaida cilvēku. Zemas ietekmes, atsaucamas darbības, piemēram, neizdevušās ziņas atkārtota nosūtīšana, var notikt bez apstiprinājuma, ja īpašnieks tam piekrīt.
Auditējamība
Katrs notikums, priekšlikums, apstiprinājums, noraidījums un izpildītā darbība tiek reģistrēti pie pasūtījuma vai pieteikuma atsauces, ar aģenta izmantotajiem datiem, modeļa un uzvednes versiju un apstiprinātāju. Apstrīdētu rēķinu vai klienta sūdzību var izsekot soli pa solim.
Datu aizsardzība
Klientu un piegādātāju kontaktinformācija nonāk tikai tajās sistēmās, kurām tā vajadzīga. Laika joslā glabājas biznesa atsauces un statusi, nevis pilni ieraksti, un žurnāli tiek glabāti Jūsu noteiktajā termiņā. Apstrāde notiek saskaņotajā reģionā.
MI pārredzamība
Aģenta priekšlikumi izņēmumu darbvietā ir attiecīgi atzīmēti, un blakus tiem redzami pierādījumi un pamatojums. Primārās sistēmas paliek noteicošās: laika līnija rāda to, ko tās ziņo, un nekad tās neaizstāj.
Rādītāji
Ko mēs mērītu
Par šiem rādītājiem mēs ar Jums vienojamies izpētes posmā, un sākotnējo stāvokli iegūstam no Jūsu pašreizējo sistēmu un saskarņu žurnāliem, pirms kaut kas mainās.
Ko mēs mērītu
Rādītājs
Kāpēc tas ir svarīgi
Kā mēs to mērītu
01Pasūtījuma cikla laiks
Kāpēc tas ir svarīgiRādītājs, ko klienti pamana pirmo, un tas, kas parāda, kur pasūtījumi gaida.
Kā mēs to mērītuLaiks no pasūtījuma saņemšanas līdz piegādei un līdz apmaksai, pa kanāliem un juridiskajām personām, pēc laika līnijas notikumiem.
02Pasūtījumi bez manuālas iejaukšanās
Kāpēc tas ir svarīgiParāda, cik liela daļa plūsmas darbojas ar tīriem datiem un saskaņotiem noteikumiem.
Kā mēs to mērītuTo pasūtījumu un pieteikumu daļa, kas līdz norēķinam nonāk bez neviena manuāla soļa vai izņēmuma, pēc laika līnijas.
03Izņēmumi pa iemesliem un atrisināšanas laiks
Kāpēc tas ir svarīgiParāda, kurus cēloņus novērst vispirms un vai izņēmumu darbvieta tiek galā.
Kā mēs to mērītuIzņēmumu apjoms pa iemeslu kodiem un laiks no atklāšanas līdz izpildītam risinājumam, pēc izņēmumu darbvietas žurnāliem.
04Noraidīto e-rēķinu īpatsvars
Kāpēc tas ir svarīgiNoraidīti rēķini aizkavē apmaksu un parasti norāda uz pamatdatu vai atbilstības shēmu kļūdām.
Kā mēs to mērītuNoraidīto nosūtīto un saņemto e-rēķinu daļa pa iemesliem, pēc piekļuves punkta atbildēm.
05Saskarņu kļūmes un atjaunošanas laiks
Kāpēc tas ir svarīgiParāda, vai integrācijas slānis ir uzticams un vai kļūmes tiek pamanītas un novērstas ātri.
Kā mēs to mērītuNeizdevušies ziņojumi katrā saskarnē un laiks no kļūmes līdz sekmīgai atkārtotai nosūtīšanai, pēc integrāciju uzraudzības.
06Pamatdatu dublikāti un konflikti
Kāpēc tas ir svarīgiLielākā daļa izņēmumu sākas ar datiem, kas sistēmās atšķiras.
Kā mēs to mērītuAtvērtie dublikāti un konfliktējošās vērtības katram datu objektam un sistēmai, pēc salīdzināšanas pārskatiem.
Kamēr nav sākotnējā mērījuma, mērķus nenosakām.
Ieviešana
Kā mēs to ieviestu
01. posms
Izpēte un procesa karte
Viens process, piemēram, no pasūtījuma līdz apmaksai vienam pārdošanas kanālam, un viens izņēmuma veids. Mēs kartējam sistēmas, saskarnes, datu īpašniekus un to, kā izņēmumi tiek risināti šodien.
Posma noslēguma kritēriji
Kartēts process, sistēmas un datu īpašnieki
Saskaņots pirmais izņēmuma veids un apstiprināšanas sliekšņi
Sākotnējais stāvoklis iegūts no pašreizējiem žurnāliem
02. posms
Integrācija un laika līnija
Dokumentētas API un notikumi tvērumā esošajām sistēmām, un laika līnija, kas darbojas līdzās esošajām saskarnēm, tās nemainot.
Posma noslēguma kritēriji
Notikumu līgumi publicēti un versēti
Laika josla izlases pasūtījumos sakrīt ar primārajām sistēmām
Atkārtota nosūtīšana un darbības rokasgrāmatas pārbaudītas
03. posms
Izņēmumu darbvietas izmēģinājums
Aģents ierosina risinājumus izvēlētajam izņēmuma veidam, un cilvēki apstiprina katru priekšlikumu. Mēs salīdzinām priekšlikumus ar to, ko būtu darījuši darbinieki.
Posma noslēguma kritēriji
Priekšlikumu kvalitāte atbilst saskaņotajiem kritērijiem
Sliekšņi un apstiprinātāji noteikti katram darbības veidam
Audita pierakstus pārskatījušas finanses un iekšējā kontrole
04. posms
Paplašināšana un veco saskarņu izslēgšana
Vairāk izņēmumu veidu, kanālu, juridisko personu un procesu, piemēram, no iepirkuma līdz maksājumam, visi uz tiem pašiem līgumiem. Vecās tiešās saskarnes tiek izslēgtas pa vienai.
Posma noslēguma kritēriji
Katra jaunā plūsma uz tiem pašiem līgumiem un uzraudzības
Pēc pasūtījuma ražotas preces un rezerves daļu pasūtījumi no ERP līdz noliktavai un pārvadātājiem, ar piegādātāju apstiprinājumiem un e-rēķiniem, kas salīdzināti ar pirkuma pasūtījumiem.
Siltumapgādes uzņēmuma apkopes darba uzdevumi vairākos objektos, no pieteikuma caur izbraukumu līdz rēķinam, un materiālu iepirkumi, kas salīdzināti ar pasūtījumiem.
No iepirkuma līdz maksājumam ar strukturētiem e-rēķiniem valsts un pašvaldību iestādēm un no tām, salīdzinātiem ar pasūtījumiem un pieņemšanas aktiem pirms apmaksas.
Ilustratīvs piemērs
Pārtikas ražotājs, kas pārdod trīs Baltijas valstīs
Situācija
Pārtikas ražotājs pārdod caur tirdzniecības ķēdēm ar EDI, savu e-veikalu un pašvaldību iestādēm Latvijā, Lietuvā un Igaunijā, no divām noliktavām. Pasūtījumus ERP sistēmā ievada vēlreiz, ražošanas plānošana tos redz ar nokavēšanos, pārvadātāji par piegādes problēmām ziņo pa e-pastu, un katrā valstī rēķinus izraksta citādi.
Sistēma
Pasūtījumi, krājumi, ražošanas plāns, sūtījumi un rēķini kā notikumi plūst starp e-veikalu, EDI, ERP, noliktavas sistēmu un pārvadātājiem, un katram pasūtījumam ir viena laika līnija. Rēķini pašvaldību iestādēm Latvijā iziet kā strukturēti e-rēķini, un tā pati plūsma ir gatava B2B e-rēķiniem no 2028. gada.
Cilvēka kontrole
Krājumu iztrūkumi un neizdevušās piegādes nonāk vienā izņēmumu darbvietā, kur aģents ierosina aizvietojošu preci vai jaunu piegādes datumu. Klientu apkalpošana apstiprina katru priekšlikumu; cenu izmaiņām un kredītrēķiniem vajadzīgs finanšu nodaļas apstiprinājums.
Ko mēs mērītu
Pasūtījumu bez manuālas iejaukšanās īpatsvars katrā valstī un kanālā, izņēmumi pa iemesliem un atrisināšanas laiks, kā arī noraidīto e-rēķinu īpatsvars katrā valstī.
Latvija
Viens process, vairākas valstis un prasības
Uzņēmumi, kas strādā Latvijā, Lietuvā, Igaunijā un citur ES, bieži darbina tos pašus procesus no pasūtījuma līdz apmaksai un no iepirkuma līdz maksājumam dažādās ERP instancēs, ar dažādiem pārvadātājiem un bankām. Valstu e-rēķinu prasības stājas spēkā dažādos datumos: Latvijā rēķini valsts un pašvaldību iestādēm jau ir strukturēti e-rēķini, B2B e-rēķinus Valsts ieņēmumu dienestam brīvprātīgi var iesniegt kopš 2026. gada 1. janvāra, un no 2028. gada 1. janvāra tie būs obligāti. ES ViDA pakete (PVN noteikumi digitālajā laikmetā) no 2030. gada 1. jūlija padara strukturētus e-rēķinus par standartu ES iekšējās B2B piegādēs. Mēs projektējam vienu integrācijas slāni, kurā katras valsts formāts un tīkls atrodas aiz tiem pašiem notikumiem, tāpēc jauna prasība nozīmē jaunu savienotāju, nevis jaunu procesu.
Datu akts, kas piemērojams kopš 2025. gada 12. septembra, nosaka noteikumus datu apstrādes pakalpojumu maiņai, tāpēc mēs notikumu līgumus un datu eksportu saglabājam pārnesamus. Aģenti izņēmumu darbvietā tiek projektēti, ņemot vērā Mākslīgā intelekta aktu, un integrācijām ir reģistrēta piekļuve un dokumentēti komponenti klientiem, kam jāpierāda piegādes ķēdes drošība saskaņā ar Nacionālās kiberdrošības likumu.
Nē. Jūsu ERP, CRM, e-veikals un noliktavas sistēma katra dara savu darbu. Mēs veidojam integrāciju ap šīm primārajām sistēmām, vienojamies, kurai sistēmai pieder kuri dati, un procesam dodam vienu laika līniju pāri tām visām. Ja veca pasūtījumu vai ERP sistēma bremzē izmaiņas, mantoto sistēmu modernizācija vispirms to novieto aiz API.
02Vai Jūs aizstājat mūsu integrācijas starpprogrammatūru?
Ne tad, ja tā dara savu darbu. Mēs būvējam uz integrācijas platformas vai ziņojumu brokera, ko Jūs jau izmantojat, un pievienojam līgumus, uzraudzību un atkārtotu nosūtīšanu tur, kur to trūkst. Ja tādas nav, mēs veidojam risinājumu mākoņvidē. Vairāk par mūsu darbu ar integrācijām.
03Vai aģenti var rīkoties paši?
Tikai sliekšņu robežās, par kuriem vienojamies katram darbības veidam, un tikai zemas ietekmes darbībām, ko var atsaukt, piemēram, neizdevušās ziņas atkārtotai nosūtīšanai. Finanšu grāmatojumiem, cenām, kredītlimitiem un saistībām pret klientiem vienmēr vajadzīgs cilvēks. Lasiet, kur MI aģentiem vajadzīgs cilvēka apstiprinājums.
04Kā tajā iekļaujas e-rēķinu prasības?
Latvijā rēķini valsts un pašvaldību iestādēm kopš 2025. gada 1. janvāra ir strukturēti e-rēķini (līgumiem, kas noslēgti līdz 2024. gada 31. decembrim, ar pārejas periodu līdz 2026. gada 1. janvārim). Kopš 2026. gada 1. janvāra uzņēmumi, kas izraksta rēķinus budžeta iestādēm, e-rēķinu datus nodod arī Valsts ieņēmumu dienestam, un kopš tā paša datuma B2B e-rēķinus VID var iesniegt brīvprātīgi. No 2028. gada 1. janvāra strukturēti e-rēķini ar ziņošanu VID būs obligāti arī starp uzņēmumiem. ES līmenī ViDA pakete (PVN noteikumi digitālajā laikmetā) no 2030. gada 1. jūlija padara strukturētus e-rēķinus par standartu ES iekšējās B2B piegādēs. Mēs e-rēķinu uzskatām par vēl vienu notikumu procesā: tas tiek izrakstīts ERP sistēmā, nosūtīts caur piekļuves punktu, un, ja to noraida, risināts izņēmumu darbvietā. Skatiet mūsu ceļvedi par e-rēķiniem un Peppol.
05Kā Jūs izvairāties no jauna trausla tiešo savienojumu tīkla?
Sistēmas publicē un patērē dokumentētus notikumus un API caur vienu slāni, nevis tiešos savienojumos savā starpā. Līgumiem tiek uzturētas versijas, saņēmēji ir idempotenti, neizdevušos ziņojumus var nosūtīt atkārtoti, un katrai plūsmai ir nosaukts īpašnieks. Jauns kanāls abonē esošos notikumus, nevis pievieno savienojumu ar katru sistēmu.
06Kā izskatās pirmais apjoms?
Viens process un viens izņēmuma veids, piemēram, no pasūtījuma līdz apmaksai vienam pārdošanas kanālam, ar krājumu iztrūkumiem kā pirmo izņēmumu. Tas pierāda notikumus, laika līniju un apstiprināšanas plūsmu, pirms tiek pievienots vairāk. Lasiet par mūsu pieeju projektu īstenošanai.
Pārrunāsim Jūsu pasūtījumu un rēķinu plūsmas
Izvēlieties vienu procesu un valstis, kurās tas darbojas. Mēs kopā ar Jums kartēsim sistēmas, saskarnes un izņēmumus un piedāvāsim pirmo versiju, kas darbojas visās Jūsu juridiskajās personās.