Vsako naročilo na eni časovnici, od prejema do plačanega računa.
Procesi od naročila do plačila (order to cash), od nabave do plačila (procure to pay) in od servisnega zahtevka do računa tečejo skozi ERP, CRM, spletno trgovino, skladišče, prevoz in računovodstvo. Povežemo jih z dokumentiranimi API-ji in dogodki, vsakemu naročilu damo eno stanje v vseh teh sistemih, vsako izjemo pa predamo agentu umetne inteligence (UI), ki pripravi predlog rešitve, o katerem odloči človek.
Za podjetja v Sloveniji, ki prodajajo, nabavljajo in izdajajo račune tudi v sosednjih državah, vsaka s svojimi sistemi, prevozniki in pravili za e-račune.
Prodajno naročilo, naročilnica ali servisni zahtevek se enkrat zabeleži v izvornem sistemu in se prek dokumentiranih API-jev in dogodkov razdeli drugim sistemom. Dogodki o stanju sestavijo eno časovnico za vsako naročilo. Ko korak ne uspe ali preseže dovoljeno odstopanje, agent UI zbere kontekst in predlaga rešitev, ki jo človek odobri, preden se izvede v izvornem sistemu. Računi se izmenjajo in uskladijo kot strukturirani e-računi, lastniki procesov pa pregledujejo pretok in delovanje vmesnikov.
Prej in potem
Kaj se spremeni v vsakdanjem poslovanju
Danes
S sistemom
Danes
Danes: Ob vsaki predaji znova pretipkano
Naročilo iz spletne trgovine ali od prodajne ekipe nekdo znova vnese v ERP, podatke o dostavi in računu pa ročno prepiše v sisteme za skladišče, prevoz in računovodstvo.
S sistemom
S sistemom: Vneseno enkrat, uporabljeno povsod
Vsako naročilo, dobavnica in račun nastane v sistemu, ki mu pripada, in se objavi kot dogodek. Drugi sistemi se nanj naročijo, namesto da bi ga pretipkavali.
Danes
Danes: Včerajšnje stanje
Zaradi nočnih paketnih prenosov služba za stranke, planiranje in računovodstvo vidijo vsak svoje, zastarelo stanje istega naročila. Stranka, ki vpraša, kje je pošiljka, čaka na povratni klic.
S sistemom
S sistemom: Eno trenutno stanje
Vsako naročilo ali zahtevek ima eno časovnico, sestavljeno iz dogodkov vseh sistemov, skozi katere gre. Služba za stranke, planiranje in računovodstvo vidijo ista dejstva, prav tako asistent, ki na vprašanja o stanju odgovarja v rešitvi Podpora strankam.
Danes
Danes: Izjeme v e-poštnih predalih
Pomanjkanje zaloge, neskladja v cenah, neuspele dostave in zavrnjeni e-računi se rešujejo po e-pošti in v preglednicah, pozneje pa nihče ne ve, kdo je kaj odločil.
S sistemom
S sistemom: Izjeme prispejo s predlogom
Agent UI zbere podatke za vsako izjemo in predlaga rešitev. Človek jo na enem zaslonu za izjeme odobri, popravi ali zavrne, odločitev pa se zabeleži.
Danes
Danes: Matični podatki, ki se ne ujemajo
Ista stranka, dobavitelj, izdelek ali cena obstaja v več sistemih z različnimi vrednostmi, za pravilno vrednost pa ni odgovoren nihče.
S sistemom
S sistemom: En lastnik za vsak podatkovni objekt
Stranke, dobavitelji, izdelki in cene imajo dogovorjen izvorni sistem in imenovanega lastnika. Dvojniki in neskladja se sporočijo temu lastniku in se ne popravljajo tiho v sistemih naprej po verigi.
Danes
Danes: Vsaka sprememba doda vmesnik
Nov prodajni kanal, spletna tržnica ali pravna oseba pomeni še eno neposredno povezavo med dvema sistemoma. Od 1. januarja 2028 bodo poslovni subjekti za dobave v Sloveniji izmenjevali samo še e-račune (ZIERDED), kar vsakemu procesu doda strukturirano obliko in pot izmenjave.
S sistemom
S sistemom: Nove povezave na obstoječih specifikacijah
Nov kanal, pravna oseba ali pot izmenjave e-računov se enkrat poveže z dokumentiranimi API-ji in dogodki, namesto z vsakim sistemom posebej.
Potek dela
Kako poteka delo
Kadar so podatki čisti, glavna pot ne zahteva ročnega dela. Ko naročilo, dostava ali račun odstopa, zanka za izjeme to predloži človeku z dokazili in predlogom, odobren popravek pa se vrne skozi isto integracijsko plast.
Ponazoritveni potek dela
7 korakov · 1 točka človeškega nadzora
Legenda
Sistem
Agent UI
Oseba
Točka človeškega nadzora
Postopek ob izjemi
Povezani procesi: ponazoritveni potek dela z zanko za izjeme
Preberite diagram kot besedilo
Glavna pot vodi od enkratnega zapisa poslovnega dogodka v izvornem sistemu prek razdelitve drugim sistemom z API-ji in dogodki ter sestave ene časovnice za vsako naročilo do izdaje računa, uskladitve in plačila. Konča se s pregledom pretoka, v katerem lastniki procesov odpravijo vzroke izjem.
Ko korak ne uspe, zamuja ali preseže dovoljeno odstopanje, izjema po koraku s časovnico zapusti glavno pot. Agent UI zbere kontekst in predlaga rešitev, človek pa jo odobri, popravi ali zavrne. Odobreno dejanje se izvede v izvornem sistemu in se kot nov dogodek vrne na korak razdelitve.
Odobritev je točka človeškega nadzora: brez človeka ni finančnega knjiženja, spremembe cene ali kreditnega limita in nobene zaveze stranki.
01
Korak 1: Enkratni zapis dogodkaSistem
Prodajno naročilo iz spletne trgovine, s spletne tržnice, prek EDI ali od prodajne ekipe, naročilnica ali servisni zahtevek nastane v sistemu, ki mu pripada. Ta sistem objavi poslovni dogodek v ovojnici CloudEvents, opisan v specifikaciji AsyncAPI. Papirnata naročila in naročila v PDF ter računi dobaviteljev, ki niso e-računi, gredo najprej skozi rešitev Obdelava dokumentov.
02
Korak 2: Razdelitev prek API-jev in dogodkovSistem
Integracijska plast dogodek dostavi sistemom za skladišče, prevoz, računovodstvo in CRM prek njihovih dokumentiranih API-jev (OpenAPI). Prejemniki so idempotentni, zato ponovljeno sporočilo nikoli ne ustvari druge pošiljke ali računa, sporočila, ki jih ni mogoče dostaviti, pa čakajo v čakalni vrsti napak na ponovno obdelavo.
03
Korak 3: Ena časovnica za naročiloSistem
Dogodki o stanju iz vseh sistemov (potrjeno, pripravljeno, odpremljeno, dostavljeno, zaračunano, plačano) se po poslovni referenci povežejo v eno časovnico. Pravila za mejnike in dovoljena odstopanja sprožijo izjemo, ko korak ne uspe, zamuja ali se ne ujema: pomanjkanje zaloge, cena zunaj dogovorjenega odstopanja, neuspela dostava, zavrnjen e-račun.
04
Korak 4: Zbiranje konteksta in predlogAgent UI
Za vsako izjemo agent UI iz vključenih sistemov prebere, kar potrebuje: naročilo, zalogo, cenovni dogovor, stanje pri prevozniku in pogoje stranke. Predlaga rešitev z utemeljitvijo in uporabljenimi podatki, na primer nadomestni izdelek, popravljeno ceno, nov termin dostave ali popravljen račun.
Postopek ob izjemi: Korak ni uspel ali je zunaj odstopanja
05
Korak 5: Odobritev v okviru pragovOseba
Zaposleni v službi za stranke, logistiki ali računovodstvu na zaslonu za izjeme vidi izjemo, dokazila in predlog ter ga odobri, popravi ali zavrne. Odobreno dejanje se izvede prek API-ja izvornega sistema, ki spremembo objavi kot nov dogodek.
Postopek ob izjemi: Korak ni uspel ali je zunaj odstopanja· Vrnitev na korak 2
Točka človeškega nadzora
Agenti nikoli ne knjižijo finančnih transakcij, ne spreminjajo cen ali kreditnih limitov in se strankam ne zavežejo brez odobritve. Pragovi za vsako vrsto dejanja določajo, kdo odobri, vsak predlog in odločitev pa se zabeležita.
06
Korak 6: Račun, uskladitev in plačiloSistem
Izdani računi zapustijo ERP kot strukturirani e-računi (e-SLOG ali sintaksa, skladna z evropskim standardom EN 16931, na primer Peppol BIS Billing 3.0) prek ponudnika e-poti ali dostopne točke Peppol. Prejeti računi dobaviteljev se uskladijo z naročilnicami in prevzemi blaga, stanje plačila iz banke ali od ponudnika plačilnih storitev pa zaključi časovnico.
07
Korak 7: Pregled pretoka in vzrokovOseba
Lastniki procesov in integracijska ekipa v rednem ritmu pregledujejo izjeme po razlogih, napake vmesnikov in neskladja matičnih podatkov. Vzrok odpravijo tam, kjer nastane, v matičnem zapisu, pravilu za odstopanja ali preslikavi, namesto da bi isto izjemo reševali znova.
Komponente
Kaj bi zgradili
01
Integracijska plast na podlagi dogodkov
API-ji in dogodki med ERP, CRM, spletno trgovino, skladiščem, prevozom in računovodstvom, najprej opredeljeni v specifikacijah OpenAPI in AsyncAPI z ovojnicami CloudEvents, na vaši obstoječi integracijski platformi ali zgrajeni v oblaku.
Dogovorjen izvorni sistem in lastnik za vsak podatkovni objekt, pravila za ujemanje strank, dobaviteljev in izdelkov ter poročila o dvojnikih in neskladjih za ljudi, ki so zanje odgovorni.
Storitev, ki dogodke poveže v eno časovnico za vsako naročilo ali zahtevek, uporablja pravila za mejnike in odstopanja ter lastnikom procesov prikazuje pretok in izjeme.
Čakalna vrsta izjem z zbranim kontekstom in predlogom agenta, z dejanji za odobritev, popravek in zavrnitev ter s pragovi odobritve za vsako vrsto dejanja, ki se uveljavijo tam, kjer se dejanje izvede.
E-računi v standardu e-SLOG ali v sintaksah, skladnih z EN 16931, kot je Peppol BIS Billing 3.0 v UBL, poslani in prejeti prek ponudnika e-poti ali dostopne točke Peppol, preverjeni pred pošiljanjem, zavrnjeni pa preusmerjeni na zaslon za izjeme.
Spremljanje delovanja in opozarjanje za vsak vmesnik, priročniki za ekipo za delovanje in nadzorovana ponovna obdelava neuspelih sporočil, uvedeno kot infrastruktura v kodi v vašem oblačnem okolju.
SAP S/4HANA za prodajo, nabavo in financePlatformaSAP
Salesforce Sales, Service in Commerce CloudPlatformaSalesforce
Odoo za prodajo, zalogo, nabavo in računovodstvoPlatformaOdoo
Platforme za spletno trgovino, spletne tržnice in API-ji prevoznikov
Sistemi za upravljanje skladišča in prevoza
Ponudnik e-poti ali dostopna točka Peppol, banke in ponudniki plačilnih storitev
Upravljanje podatkov o izdelkih in podatkovna platforma
Nadzorni mehanizmi
Vgrajeni nadzorni mehanizmi
Omejitve dostopa
Vsaka integracija in agent delujejo pod lastno identiteto storitve v vsakem sistemu, omejeno na operacije API, ki jih potrebujejo. Agent lahko za zbiranje konteksta bere v več sistemih, piše pa lahko samo prek kratkega seznama odobrenih dejanj, ki jih izvede API izvornega sistema, nikoli z neposrednim dostopom do baze podatkov.
Človeški pregled
Pragove odobritve za vsako vrsto dejanja določimo z lastnikom procesa: kaj agent lahko samo predlaga, kaj odobri član ekipe in kaj zahteva drugega odobritelja. Finančna knjiženja, spremembe cen in kreditnih limitov ter zaveze strankam vedno počakajo na človeka. Dejanja z majhnim vplivom, ki jih je mogoče razveljaviti, kot je ponovni poskus neuspelega sporočila, lahko potekajo brez odobritve, če se lastnik s tem strinja.
Revizijska sledljivost
Vsak dogodek, predlog, odobritev, zavrnitev in izvedeno dejanje se zabeleži pod referenco naročila ali zahtevka, s podatki, ki jih je agent uporabil, z različico modela in navodil ter z odobriteljem. Sporni račun ali pritožbo stranke je mogoče izslediti korak za korakom.
Varstvo podatkov
Kontaktni podatki strank in dobaviteljev gredo samo v sisteme, ki jih potrebujejo. Časovnica hrani poslovne reference in stanja, ne celotnih zapisov, dnevniki pa se hranijo toliko časa, kot določite. Obdelava poteka v dogovorjeni regiji.
Preglednost UI
Predlogi agenta so na zaslonu za izjeme označeni kot taki, ob njih pa sta prikazana dokazila in utemeljitev. Izvorni sistemi ostanejo merodajni: časovnica prikazuje, kar ti sporočajo, in jih nikoli ne povozi.
Kazalniki
Kaj bi merili
Kazalnike z vami dogovorimo med začetno analizo, izhodiščno stanje pa vzamemo iz dnevnikov vaših sistemov in vmesnikov, preden se kar koli spremeni.
Kaj bi merili
Kazalnik
Zakaj je pomemben
Kako bi ga merili
01Čas cikla naročila
Zakaj je pomembenKazalnik, ki ga stranke opazijo najprej in ki pokaže, kje naročila čakajo.
Kako bi ga meriliČas od prejema naročila do dostave in do plačila, po kanalu in pravni osebi, iz dogodkov na časovnici.
02Naročila brez ročnega posega
Zakaj je pomembenPokaže, kolikšen del pretoka teče na čistih podatkih in dogovorjenih pravilih.
Kako bi ga meriliDelež naročil in zahtevkov, ki pridejo do plačila brez ročnega koraka ali izjeme, iz časovnice.
03Izjeme po razlogih in čas reševanja
Zakaj je pomembenPove, katere vzroke odpraviti najprej in ali zaslon za izjeme dohaja delo.
Kako bi ga meriliŠtevilo izjem po šifri razloga in čas od zaznave do izvedene rešitve, iz dnevnikov zaslona za izjeme.
04Delež zavrnjenih e-računov
Zakaj je pomembenZavrnjeni računi zamaknejo plačilo in običajno kažejo na napake v matičnih podatkih ali preslikavah.
Kako bi ga meriliDelež poslanih in prejetih e-računov, ki so bili zavrnjeni, po razlogu, iz odgovorov ponudnika e-poti ali dostopne točke.
05Napake vmesnikov in čas obnovitve
Zakaj je pomembenPokaže, ali je integracijska plast zanesljiva ter ali se napake hitro opazijo in odpravijo.
Kako bi ga meriliNeuspela sporočila po vmesniku in čas od napake do uspešne ponovne obdelave, iz spremljanja integracij.
06Dvojniki in neskladja matičnih podatkov
Zakaj je pomembenVečina izjem izvira iz podatkov, ki se med sistemi razlikujejo.
Kako bi ga meriliOdprti dvojniki in neskladne vrednosti po podatkovnem objektu in sistemu, iz poročil o ujemanju.
Dokler izhodiščno stanje ni znano, ciljnih vrednosti ne določamo.
Uvedba
Kako bi rešitev uvedli
Faza 01
Začetna analiza in zemljevid procesa
En proces, na primer od naročila do plačila za en prodajni kanal, in ena vrsta izjeme. Popišemo sisteme, vmesnike, lastnike podatkov in današnji način reševanja izjem.
Merila za zaključek
Proces, sistemi in lastniki podatkov so popisani
Prva vrsta izjeme in pragovi odobritve so dogovorjeni
Izhodiščno stanje je vzeto iz obstoječih dnevnikov
Faza 02
Integracija in časovnica
Dokumentirani API-ji in dogodki za vključene sisteme ter časovnica, ki teče ob obstoječih vmesnikih in jih ne spreminja.
Merila za zaključek
Specifikacije dogodkov so objavljene in imajo različice
Časovnica se na vzorcu naročil ujema z izvornimi sistemi
Ponovna obdelava in priročniki so preizkušeni
Faza 03
Pilot zaslona za izjeme
Agent predlaga rešitve za izbrano vrsto izjeme, ljudje pa odobrijo vsak predlog. Predloge primerjamo s tem, kar bi naredili zaposleni.
Merila za zaključek
Kakovost predlogov dosega dogovorjena merila
Pragovi in odobritelji so določeni za vsako vrsto dejanja
Revizijsko sled sta pregledala računovodstvo in notranja kontrola
Faza 04
Razširitev in ukinitev
Več vrst izjem, kanalov, pravnih oseb in procesov, kot je od nabave do plačila, vse na istih specifikacijah. Stare neposredne povezave med sistemi izklapljamo eno za drugo.
Merila za zaključek
Vsak nov pretok teče na istih specifikacijah in spremljanju
Naročila po meri in naročila rezervnih delov pri dobaviteljih za avtomobilsko industrijo, od ERP do skladišča in prevoznikov, s potrditvami dobaviteljev in e-računi, usklajenimi z naročilnicami.
Zahtevki za priključke in montažo pri komunalnih podjetjih, od delovnega naloga prek terenskega obiska do računa, z nabavo materiala pri pogodbenih dobaviteljih.
Delovni nalogi za vzdrževanje voznega parka, naročilnice izvajalcem in njihovi računi pri mestnih in regionalnih avtobusnih prevoznikih, od zahtevka do plačila.
Od nabave do plačila v bolnišnici ali drugem javnem zavodu, ki kot proračunski uporabnik že od leta 2015 prejema samo e-račune prek UJP, usklajene z naročilnicami in prevzemi pred plačilom.
Ponazoritveni primer
Distributer, ki prodaja v treh državah
Izhodišče
Distributer tehničnega materiala s sedežem v Sloveniji prodaja prek spletne trgovine, dveh spletnih tržnic in terenske prodaje v Sloveniji, na Hrvaškem in v Avstriji, iz dveh skladišč. Naročila se v ERP vnašajo znova, prevozniki težave z dostavo sporočajo po e-pošti, vsaka država pa račune izdaja po svoje.
Sistem
Naročila, zaloga, pošiljke in računi tečejo kot dogodki med spletno trgovino, ERP, skladiščnim sistemom in prevozniki, vsako naročilo pa ima eno časovnico. Računi odidejo kot strukturirani e-računi v obliki in po poti, ki ju zahteva posamezna država, za Slovenijo od 1. januarja 2028 prek ponudnika e-poti ali dostopne točke Peppol.
Človeški nadzor
Pomanjkanje zaloge in neuspele dostave pristanejo na enem zaslonu za izjeme, kjer agent predlaga nadomestni izdelek ali nov datum dostave. Služba za stranke odobri vsak predlog, spremembe cen in dobropisi pa zahtevajo odobritev računovodstva.
Kaj bi merili
Delež naročil brez ročnega posega po državi in kanalu, izjeme po razlogih in čas reševanja ter delež zavrnjenih e-računov po državi.
Slovenija
En proces, več držav in pravil za e-račune
Slovenska podjetja pogosto prodajajo v Avstrijo, Nemčijo, Italijo in na Hrvaško ali so del skupin s sedežem tam, zato isti proces od naročila do plačila teče na različnih ERP, pri različnih prevoznikih in bankah. Od 1. januarja 2028 bodo poslovni subjekti za dobave v Sloveniji izmenjevali samo e-račune (ZIERDED), proračunski uporabniki pa jih prek UJP prejemajo že od leta 2015. Druge države uvajajo obveznosti ob drugih datumih, paket EU o DDV za digitalno dobo pa od 1. julija 2030 strukturirane e-račune uvaja kot privzeto pravilo za dobave B2B znotraj EU. Zasnujemo eno integracijsko plast, v kateri sta oblika in pot vsake države za istimi dogodki, zato nova obveznost pomeni nov priključek, ne novega procesa.
Akt o podatkih, ki se uporablja od 12. septembra 2025, določa pravila za menjavo ponudnikov storitev obdelave podatkov, zato specifikacije dogodkov in izvoze podatkov ohranjamo prenosljive. Agente na zaslonu za izjeme načrtujemo ob upoštevanju Akta o umetni inteligenci, integracije pa imajo zabeležen dostop in dokumentirane komponente za stranke, ki morajo po direktivi NIS 2 in Zakonu o informacijski varnosti (ZInfV-1) izkazati varnost dobavne verige.
Ne. Vaš ERP, CRM, spletna trgovina in skladiščni sistem opravljajo vsak svoje delo. Integracijo zgradimo okoli teh izvornih sistemov, dogovorimo, kateri sistem je lastnik katerih podatkov, procesu pa damo eno časovnico prek vseh. Kadar star sistem za naročila ali ERP zavira spremembe, ga rešitev Posodobitev starejših sistemov najprej postavi za API-je.
Ne, če opravlja svoje delo. Gradimo na integracijski platformi ali posredniku sporočil, ki ga že uporabljate, in dodamo specifikacije, spremljanje in ponovno obdelavo, kjer manjkajo. Kjer platforme ni, gradimo v oblaku. Več o tem na strani Integracije in API-ji.
03Ali lahko agenti delujejo sami?
Samo v okviru pragov, ki jih dogovorite za vsako vrsto dejanja, in samo pri dejanjih z majhnim vplivom, ki jih je mogoče razveljaviti, kot je ponovni poskus neuspelega sporočila. Finančna knjiženja, cene, kreditni limiti in zaveze strankam vedno zahtevajo človeka. Preberite članek o tem, kje agenti UI potrebujejo odobritev človeka.
04Kako se v to umeščajo e-računi?
Od 1. januarja 2028 bodo poslovni subjekti za dobave blaga in storitev v Sloveniji izmenjevali samo e-račune (ZIERDED), v standardu e-SLOG ali v sintaksi, skladni z evropskim standardom, prek registriranega ponudnika e-poti, omrežja Peppol ali neposredno, ne pa po e-pošti; račun v PDF ni e-račun. Seznam ponudnikov e-poti UJP vzpostavi 1. oktobra 2027. Druge države uvajajo obveznosti ob drugih datumih, paket EU o DDV za digitalno dobo (ViDA) pa od 1. julija 2030 strukturirane e-račune uvaja kot privzeto pravilo za dobave B2B znotraj EU. E-račun obravnavamo kot še en dogodek v procesu: izda ga ERP, pošlje se prek ponudnika e-poti ali dostopne točke, če je zavrnjen, pa se obravnava na zaslonu za izjeme. Preberite naš vodnik po e-računih in omrežju Peppol.
05Kako se izognete novi krhki mreži neposrednih povezav?
Sistemi objavljajo in porabljajo dokumentirane dogodke in API-je prek ene plasti, ne prek neposrednih povezav med seboj. Specifikacije imajo različice, prejemniki so idempotentni, neuspela sporočila je mogoče ponovno obdelati, vsak pretok pa ima imenovanega lastnika. Nov kanal se naroči na obstoječe dogodke, namesto da bi dodal povezavo z vsakim sistemom.
06Kako je videti prvi obseg?
En proces in ena vrsta izjeme, na primer od naročila do plačila za en prodajni kanal, s pomanjkanjem zaloge kot prvo izjemo. Tako preverimo dogodke, časovnico in potek odobritve, preden dodamo več. Kako izvajamo projekte, opisuje stran Naš pristop.
Kako tečejo vaša naročila in računi?
Izberite en proces in države, v katerih teče. Z vami bomo popisali sisteme, vmesnike in izjeme ter predlagali prvo različico rešitve, ki deluje v vseh vaših pravnih osebah.