Iga tellimus ühel ajajoonel, vastuvõtust tasutud arveni.
Order to cash (tellimusest laekumiseni), procure to pay (ostust maksmiseni) ja teenusepäringust arveni kulgevad läbi ERP-, CRM-, e-poe-, lao-, transpordi- ja finantssüsteemide. Ühendame need dokumenteeritud API-de ja sündmustega, anname igale tellimusele ühe oleku üle kõigi süsteemide ja saadame iga erandi TI-agendile, kes valmistab ette lahenduse, mille inimene kinnitab.
Organisatsioonidele, kes müüvad, ostavad ja arveldavad Eestis ja teistes liikmesriikides, mitme süsteemi, vedaja ja e-arve kanaliga.
Müügitellimus, ostutellimus või teenusepäring registreeritakse üks kord oma põhisüsteemis ja jagatakse teistele süsteemidele dokumenteeritud API-de ja sündmuste kaudu. Olekusündmustest tekib iga tellimuse kohta üks ajajoon. Kui samm ebaõnnestub või jääb lubatud hälbest välja, kogub agent konteksti ja pakub lahenduse, mille inimene kinnitab, enne kui see põhisüsteemis täidetakse. Arved vahetatakse ja sobitatakse struktureeritud e-arvetena ning protsessiomanikud vaatavad üle voo ja liideste seisu.
Enne ja pärast
Mis igapäevatöös muutub
Täna
Süsteemiga
Täna
Täna: Iga üleandmise juures uuesti sisestatud
E-poes või müügimeeskonna võetud tellimus trükitakse uuesti ERP-sse ning tarne- ja arveandmed kopeeritakse käsitsi lao-, transpordi- ja finantssüsteemi.
Süsteemiga
Süsteemiga: Sisestatakse üks kord, kasutatakse kõikjal
Iga tellimus, tarne ja arve luuakse süsteemis, mis selle eest vastutab, ja avaldatakse sündmusena. Teised süsteemid tellivad selle sündmuse, selle asemel et andmeid uuesti trükkida.
Täna
Täna: Eilne olek
Öiste pakkliideste tõttu näevad klienditeenindus, planeerimine ja finants sama tellimuse kohta erinevat ja vananenud seisu. Klient, kes küsib, kus tarne on, saab tagasihelistamise.
Süsteemiga
Süsteemiga: Üks ajakohane olek
Igal tellimusel või päringul on üks ajajoon, mis on koostatud kõigi läbitud süsteemide sündmustest. Klienditeenindus, planeerimine ja finants näevad samu fakte, nagu ka teeninduse tugi, mis vastab oleku küsimustele.
Täna
Täna: Erandid postkastides
Laovaru puudujäägid, hinnaerinevused, ebaõnnestunud tarned ja tagasi lükatud e-arved lahendatakse e-kirjade ja tabelitega ning hiljem ei oska keegi öelda, kes mida otsustas.
Süsteemiga
Süsteemiga: Erand saabub koos ettepanekuga
Agent kogub iga erandi taga olevad andmed ja pakub lahenduse. Inimene kinnitab, muudab või lükkab selle erandite töölaual tagasi ja otsus registreeritakse.
Täna
Täna: Põhiandmed, mis ei klapi
Sama klient, tarnija, toode või hind on mitmes süsteemis erinevate väärtustega ja keegi ei vastuta selle eest, milline on õige.
Süsteemiga
Süsteemiga: Igal andmeobjektil üks omanik
Klientidel, tarnijatel, toodetel ja hindadel on kokkulepitud põhisüsteem ja nimeline omanik. Duplikaatidest ja vastuoludest teavitatakse omanikku, neid ei parandata vaikselt järgmistes süsteemides.
Täna
Täna: Iga muudatus lisab liidese
Uus müügikanal, turuplats või juriidiline isik tähendab järjekordset punkt-punkt ühendust. E-arve nõuded lisavad igale protsessile veel struktureeritud vormingu ja edastuskanali.
Süsteemiga
Süsteemiga: Uued ühendused kasutavad samu liideselepinguid
Uus kanal, juriidiline isik või e-arve operaator ühendub dokumenteeritud API-de ja sündmustega üks kord, mitte iga süsteemiga eraldi.
Töövoog
Kuidas töövoog kulgeb
Kui andmed on korras, ei vaja põhitee käsitööd. Kui tellimus, tarne või arve kaldub kõrvale, toob erandite tsükkel selle inimese ette koos tõendite ja ettepanekuga ning kinnitatud parandus liigub tagasi läbi sama integratsioonikihi.
Illustreeriv töövoog
7 sammu · 1 inimese kontrollpunkt
Legend
Süsteem
TI-agent
Inimene
Inimese kontrollpunkt
Erandi käsitlus
Ühendatud protsessid: illustreeriv töövoog koos erandite tsükliga
Lugege joonist tekstina
Põhitee kulgeb ärisündmuse ühekordsest registreerimisest põhisüsteemis, selle jagamisest teistele süsteemidele API-de ja sündmuste kaudu ning tellimuse ajajoone koostamisest arveldamise, sobitamise ja tasumiseni. See lõpeb sellega, et protsessiomanikud vaatavad voo üle ja parandavad erandite põhjused.
Kui samm ebaõnnestub, hilineb või jääb lubatud hälbest välja, lahkub erand põhiteelt pärast ajajoone sammu. Agent kogub konteksti ja pakub lahenduse ning inimene kinnitab, muudab või lükkab selle tagasi. Kinnitatud toiming täidetakse põhisüsteemis ja naaseb uue sündmusena jagamise sammu.
Kinnitamise samm on inimese kontrollpunkt: ühtegi finantskannet, hinna või krediidilimiidi muudatust ega kohustust kliendi ees ei tehta ilma inimeseta.
01
Samm 1: Sündmuse registreerimine üks kordSüsteem
Müügitellimus e-poest, turuplatsilt, EDI kaudu või müügimeeskonnalt, ostutellimus või teenusepäring luuakse süsteemis, mis selle eest vastutab. See süsteem avaldab ärisündmuse CloudEventsi ümbrikus, mida kirjeldab AsyncAPI leping. Paber- ja PDF-tellimused ning tarnijate arved läbivad kõigepealt dokumenditöötluse.
02
Samm 2: Jagamine API-de ja sündmuste kauduSüsteem
Integratsioonikiht toimetab sündmuse lao-, transpordi-, finants- ja CRM-süsteemidele nende dokumenteeritud API-de (OpenAPI) kaudu. Tarbijad on idempotentsed, nii et korduv sõnum ei loo kunagi teist saadetist ega arvet, ja sõnumid, mida ei õnnestu kohale toimetada, ootavad veajärjekorras uuesti saatmist.
03
Samm 3: Üks ajajoon tellimuse kohtaSüsteem
Kõigi süsteemide olekusündmused (kinnitatud, komplekteeritud, lähetatud, kohale toimetatud, arveldatud, tasutud) seotakse ärilise viite alusel üheks ajajooneks. Verstaposti- ja hälbereeglid tekitavad erandi, kui samm ebaõnnestub, hilineb või ei klapi: laovaru puudujääk, kokkulepitud hälbest väljas hind, ebaõnnestunud tarne, tagasi lükatud e-arve.
04
Samm 4: Konteksti kogumine ja ettepanekTI-agent
Iga erandi puhul loeb agent asjassepuutuvatest süsteemidest vajaliku: tellimuse, laoseisu, hinnakokkuleppe, vedaja oleku ja kliendi tingimused. Ta pakub lahenduse koos põhjenduse ja kasutatud andmetega, näiteks asenduskauba, parandatud hinna, uue tarneaja või parandatud arve.
Erandi käsitlus: Samm ebaõnnestus või on hälbest väljas
05
Samm 5: Kinnitamine lävendite piiresInimene
Klienditeeninduse, logistika või finantsi töötaja näeb erandite töölaual erandit, tõendeid ja ettepanekut ning kinnitab, muudab või lükkab selle tagasi. Kinnitatud toiming täidetakse põhisüsteemi API kaudu ja see süsteem avaldab muudatuse uue sündmusena.
Erandi käsitlus: Samm ebaõnnestus või on hälbest väljas· Naaseb sammu 2 juurde
Inimese kontrollpunkt
Agendid ei tee kunagi ilma kinnituseta finantskandeid, ei muuda hindu ega krediidilimiite ega võta kliendi ees kohustusi. Lävendid toimingu liigi kaupa määravad, kes kinnitab, ning iga ettepanek ja otsus logitakse.
06
Samm 6: Arveldamine, sobitamine ja tasumineSüsteem
Väljaminevad arved lahkuvad ERP-st struktureeritud e-arvetena (EN 16931) e-arve operaatori kaudu; välismaa klientidele saab neid saata ka Peppoli võrgu kaudu (Peppol BIS Billing 3.0). Tarnijate arved sobitatakse ostutellimuste ja kaupade vastuvõtuga ning panga või makseteenuse pakkuja makse olek sulgeb ajajoone.
07
Samm 7: Voo ülevaatus ja põhjuste parandamineInimene
Protsessiomanikud ja integratsioonimeeskond vaatavad kindla rütmiga üle erandid põhjuse kaupa, liideste tõrked ja põhiandmete vastuolud. Nad parandavad põhjuse seal, kus see asub, põhiandmete kirjes, hälbereeglis või vastenduses, selle asemel et sama erandit uuesti lahendada.
Komponendid
Mida me ehitaksime
01
Sündmuspõhine integratsioonikiht
Lepingupõhised API-d ja sündmused ERP, CRM-i, e-poe, lao, transpordi ja finantsi vahel, kirjeldatud OpenAPI ja AsyncAPI abil CloudEventsi ümbrikes, teie olemasoleval integratsiooniplatvormil või pilvepõhiselt ehitatuna.
Kokkulepitud põhisüsteem ja omanik iga andmeobjekti jaoks, klientide, tarnijate ja toodete sobitusreeglid ning aruanded duplikaatide ja vastuolude kohta neile, kes andmete eest vastutavad.
Teenus, mis seob sündmused üheks ajajooneks tellimuse või päringu kohta, rakendab verstaposti- ja hälbereegleid ning näitab protsessiomanikele voogu ja erandeid.
Erandite järjekord, mis näitab kogutud konteksti ja agendi ettepanekut, kinnitamise, muutmise ja tagasilükkamise toimingutega ning toimingu liigi kaupa kehtivate kinnituslävenditega seal, kus toiming täidetakse.
EN 16931 kohased e-arved, mis saadetakse ja võetakse vastu e-arve operaatori kaudu ning piiriüleselt Peppol BIS Billing 3.0 vormingus, kontrollitakse enne saatmist ning tagasi lükatud arved suunatakse erandite töölauale.
Iga liidese seire ja hoiatused, käitusjuhendid käitusmeeskonnale ja ebaõnnestunud sõnumite kontrollitud uuesti saatmine, paigaldatud taristu koodina teie pilvekeskkonda.
Salesforce Sales, Service ja Commerce CloudPlatvormSalesforce
Odoo müük, ladu, ost ja raamatupidaminePlatvormOdoo
E-kaubanduse platvormid, turuplatsid ja vedajate API-d
Lao- ja transpordijuhtimise süsteemid
E-arve operaator, Peppoli pääsupunkt, pangad ja makseteenuse pakkujad
Tooteinfo haldus ja andmeplatvorm
Kontrollid
Sisse ehitatud kontrollid
Juurdepääsu piirid
Iga liidestus ja agent töötab igas süsteemis oma teenuseidentiteediga, piiratud nende API toimingutega, mida see vajab. Agent tohib konteksti kogumiseks lugeda mitmest süsteemist, kuid kirjutada saab ainult lühikese heakskiidetud toimingute loetelu kaudu, mida täidab põhisüsteemi API, ja mitte kunagi otsese juurdepääsuga andmebaasile.
Inimese kontroll
Kinnituslävendid seatakse toimingu liigi kaupa koos protsessiomanikuga: mida agent tohib ainult pakkuda, mida kinnitab meeskonnaliige ja mis vajab teist kinnitajat. Finantskanded, hinna ja krediidilimiidi muudatused ning kohustused klientide ees ootavad alati inimest. Väikese mõjuga ja tagasipööratavad toimingud, näiteks ebaõnnestunud sõnumi uuesti saatmine, võivad omaniku nõusolekul toimuda ilma kinnituseta.
Auditeeritavus
Iga sündmus, ettepanek, kinnitus, tagasilükkamine ja täidetud toiming logitakse tellimuse või päringu viite juurde koos agendi kasutatud andmete, mudeli ja viiba versiooni ning kinnitajaga. Vaidlustatud arvet või kliendi kaebust saab jälgida samm-sammult.
Andmekaitse
Klientide ja tarnijate kontaktandmed liiguvad ainult süsteemidesse, mis neid vajavad. Ajajoon hoiab ärilisi viiteid ja olekuid, mitte terviklikke kirjeid, ning logid järgivad teie määratud säilitusaega. Töötlemine toimub kokkulepitud regioonis.
TI läbipaistvus
Agendi ettepanekud on erandite töölaual sellisena märgitud ning nende kõrval on näha tõendid ja põhjendus. Põhisüsteemid jäävad määravaks: ajajoon näitab, mida need teatavad, ega kirjuta neid kunagi üle.
Mõõdikud
Mida me mõõdaksime
Lepime need mõõdikud teiega kokku kaardistamise ajal ja võtame lähtetaseme teie praeguste süsteemide ja liideste logidest, enne kui midagi muutub.
Mida me mõõdaksime
Mõõdik
Miks see on oluline
Kuidas me seda mõõdaksime
01Tellimuse tsükliaeg
Miks see on olulineMõõdik, mida klient märkab esimesena ja mis näitab, kus tellimused ootavad.
Kuidas me seda mõõdaksimeAeg tellimuse saamisest tarneni ja makseni, kanali ja juriidilise isiku kaupa, ajajoone sündmuste põhjal.
02Käsitööta tellimused
Miks see on olulineNäitab, kui suur osa voost töötab korras andmete ja kokkulepitud reeglite peal.
Kuidas me seda mõõdaksimeNende tellimuste ja päringute osakaal, mis jõuavad tasumiseni ilma ühegi käsitsi sammu või eranditeta, ajajoone põhjal.
03Erandid põhjuse kaupa ja lahendamise aeg
Miks see on olulineNäitab, milliseid põhjuseid parandada kõigepealt ja kas erandite töölaud jõuab järele.
Kuidas me seda mõõdaksimeErandite maht põhjusekoodi kaupa ning aeg avastamisest täidetud lahenduseni, erandite töölaua logidest.
04E-arvete tagasilükkamise määr
Miks see on olulineTagasi lükatud arved lükkavad makse edasi ja osutavad tavaliselt põhiandmete või vastenduse vigadele.
Kuidas me seda mõõdaksimeSaadetud ja saadud e-arvete tagasilükatud osakaal põhjuse kaupa, e-arve operaatori vastuste põhjal.
05Liideste tõrked ja taastumisaeg
Miks see on olulineNäitab, kas integratsioonikiht on töökindel ning kas tõrked märgatakse ja parandatakse kiiresti.
Kuidas me seda mõõdaksimeEbaõnnestunud sõnumid liidese kohta ning aeg tõrkest eduka uuesti saatmiseni, integratsiooni seirest.
06Põhiandmete duplikaadid ja vastuolud
Miks see on olulineEnamik erandeid saab alguse andmetest, mis süsteemide vahel erinevad.
Kuidas me seda mõõdaksimeLahtised duplikaadid ja vastuolulised väärtused andmeobjekti ja süsteemi kaupa, sobitusaruannetest.
Enne lähtetaseme mõõtmist eesmärke ei seata.
Kasutuselevõtt
Kuidas me selle kasutusele võtaksime
Etapp 01
Kaardistamine ja protsessikaart
Üks protsess, näiteks order to cash ühe müügikanali jaoks, ja üks erandi liik. Kaardistame süsteemid, liidesed, andmete omanikud ja selle, kuidas erandeid täna käsitletakse.
Lõpetamise tingimused
Protsess, süsteemid ja andmete omanikud kaardistatud
Esimene erandi liik ja kinnituslävendid kokku lepitud
Lähtetase praegustest logidest võetud
Etapp 02
Integratsioon ja ajajoon
Dokumenteeritud API-d ja sündmused ulatusse kuuluvatele süsteemidele ning ajajoon, mis töötab olemasolevate liideste kõrval neid muutmata.
Lõpetamise tingimused
Sündmuste lepingud avaldatud ja versioonitud
Ajajoon vastab valimisse võetud tellimustel põhisüsteemidele
Uuesti saatmine ja käitusjuhendid testitud
Etapp 03
Erandite töölaua pilootprojekt
Agent pakub valitud erandi liigile lahendusi ja inimesed kinnitavad iga ettepaneku. Võrdleme ettepanekuid sellega, mida töötajad oleksid teinud.
Lõpetamise tingimused
Ettepanekute kvaliteet vastab kokkulepitud kriteeriumidele
Lävendid ja kinnitajad toimingu liigi kaupa seatud
Auditijälg finantsi ja sisekontrolli poolt üle vaadatud
Etapp 04
Laiendamine ja vanade liideste mahavõtmine
Rohkem erandi liike, kanaleid, juriidilisi isikuid ja protsesse, nagu procure to pay, kõik samade lepingute peal. Vanad punkt-punkt liidesed lülitatakse välja ükshaaval.
Procure to pay struktureeritud e-arvetega avaliku sektori asutustele ja nendelt, sobitatud tellimuste ja vastuvõtuga enne makset.
Illustreeriv näide
Hulgimüüja tellimusest laekumiseni
Olukord
Ehitus- ja tehnikakaupade hulgimüüja müüb e-poe, kahe turuplatsi ja müügiesindajate kaudu Eestis, Lätis ja Soomes kahest laost. Tellimused trükitakse ERP-sse uuesti, vedajad teatavad tarneprobleemidest e-kirjaga ja avaliku sektori ostjad saavad arve ainult struktureeritud e-arvena.
Süsteem
Tellimused, laoseis, saadetised ja arved liiguvad sündmustena e-poe, ERP, laosüsteemi ja vedajate vahel ning igal tellimusel on üks ajajoon. Arved lahkuvad struktureeritud e-arvetena e-arve operaatori kaudu; välismaa klientidele lähevad need Peppoli võrgu kaudu seal, kus klient seda kasutab.
Inimese kontroll
Laovaru puudujäägid ja ebaõnnestunud tarned jõuavad ühele erandite töölauale, kus agent pakub asenduskauba või uue tarnekuupäeva. Klienditeenindus kinnitab iga ettepaneku; hinnamuudatused ja kreeditarved vajavad finantsi kinnitust.
Mida me mõõdaksime
Käsitööta tellimuste osakaal riigi ja kanali kaupa, erandid põhjuse kaupa ja lahendamise aeg ning e-arvete tagasilükkamise määr.
Eesti
Üks protsess, e-arve Eesti reeglite järgi
Eestis tohib avaliku sektori ostjatele alates 1. juulist 2019 esitada ainult struktureeritud e-arveid, mis liiguvad e-arve operaatorite kaudu, ja alates 1. juulist 2025 võib ka e-arve saajaks registreeritud ettevõte nõuda tarnijalt e-arvet. Eksportijatel lisanduvad teiste riikide nõuded ja Peppoli võrk piiriüleste arvete jaoks. Kavandame ühe integratsioonikihi, kus iga kanal ja vorming on samade sündmuste taga, nii et uus nõue tähendab uut liidest, mitte uut protsessi.
Andmemäärus, mida kohaldatakse alates 12. septembrist 2025, seab reeglid andmetöötlusteenuste vahetamisele, seepärast hoiame sündmuste lepingud ja andmeekspordi teisaldatavana. Erandite töölaua agendid kavandame tehisintellekti määrust silmas pidades ning liidestused tulevad logitud juurdepääsu ja dokumenteeritud komponentidega klientidele, kes peavad küberturvalisuse seaduse (KüTS) järgi tõendama tarneahela turvalisust.
Ei. Teie ERP, CRM, e-pood ja laosüsteem teevad igaüks oma tööd. Liidestame nende põhisüsteemide ümber, lepime kokku, milline süsteem milliste andmete eest vastutab, ja anname protsessile ühe ajajoone üle nende kõigi. Kui vana tellimus- või ERP-süsteem takistab muutusi, viib pärandsüsteemide moderniseerimine selle kõigepealt API-de taha.
02Kas asendate meie integratsiooni vahevara?
Mitte siis, kui see oma tööd teeb. Ehitame teie juba kasutatava integratsiooniplatvormi või sõnumivahendaja peale ning lisame lepingud, seire ja uuesti saatmise seal, kus need puuduvad. Kui sellist ei ole, ehitame pilvepõhiselt. Lähemalt meie liidestustööst.
03Kas agendid võivad tegutseda iseseisvalt?
Ainult toimingu liigi kaupa kokkulepitud lävendite piires ja ainult väikese mõjuga tagasipööratavate toimingute puhul, näiteks ebaõnnestunud sõnumi uuesti saatmine. Finantskanded, hinnad, krediidilimiidid ja kohustused klientide ees vajavad alati inimest. Lugege, kus TI-agendid vajavad inimese kinnitust.
04Kuidas sobituvad siia e-arve nõuded?
Eestis tohib avaliku sektori ostjatele alates 1. juulist 2019 esitada ainult struktureeritud e-arveid ja alates 1. juulist 2025 võib ka e-arve saajaks registreeritud ettevõte nõuda tarnijalt e-arvet. Euroopa Liidu pakett „Käibemaks digiajastul“ (ViDA) muudab struktureeritud e-arve alates 1. juulist 2030 vaikimisi nõudeks liikmesriikide vaheliste B2B tarnete puhul. Käsitleme e-arvet protsessi järjekordse sündmusena: see väljastatakse ERP-st, saadetakse e-arve operaatori kaudu ja käsitletakse erandite töölaual, kui see tagasi lükatakse. Vaadake meie e-arve juhendit.
05Kuidas vältida järjekordset haprat punkt-punkt ühenduste võrku?
Süsteemid avaldavad ja tarbivad dokumenteeritud sündmusi ja API-sid ühe kihi kaudu, mitte otseühendustega üksteisele. Lepingud on versioonitud, tarbijad idempotentsed, ebaõnnestunud sõnumeid saab uuesti saata ja igal vool on nimeline omanik. Uus kanal tellib olemasolevad sündmused, selle asemel et lisada ühendus iga süsteemiga.
06Milline on esimene ulatus?
Üks protsess ja üks erandi liik, näiteks order to cash ühe müügikanali jaoks, kus esimene erand on laovaru puudujääk. See tõendab sündmused, ajajoone ja kinnitusvoo, enne kui lisandub rohkem. Lugege lähemalt meie lähenemisest.
Arutame teie tellimus- ja arvevooge
Valige üks protsess. Kaardistame koos teiega süsteemid, liidesed ja erandid ning pakume välja esimese versiooni, mis töötab kõigi teie juriidiliste isikute jaoks.