Jokainen tilaus yhdellä aikajanalla vastaanotosta maksettuun laskuun.
Tilauksesta maksuun, hankinnasta maksuun ja palvelupyynnöstä laskuun kulkevat ERP:n, CRM:n, verkkokaupan, varaston, kuljetusten ja taloushallinnon järjestelmien läpi. Yhdistämme ne dokumentoiduilla rajapinnoilla ja tapahtumilla, annamme jokaiselle tilaukselle yhden tilan kaikissa järjestelmissä ja ohjaamme jokaisen poikkeuksen agentille, joka valmistelee ratkaisun ihmisen hyväksyttäväksi.
Organisaatioille, jotka myyvät, ostavat ja laskuttavat Suomessa ja muissa EU-maissa, kussakin omine järjestelmineen, kuljetusliikkeineen ja verkkolaskusääntöineen.
02Jakelu rajapintojen ja tapahtumien kauttaJärjestelmä
03Yksi aikajana tilausta kohdenJärjestelmä
04Taustatiedot ja ehdotusTekoälyagentti
05Hyväksyntä raja-arvojen puitteissaHenkilö
06Laskutus, täsmäytys ja maksuJärjestelmä
07Virran seuranta ja syiden korjausHenkilö
Tilaus, ostotilaus tai palvelupyyntö kirjataan kerran sen omistavaan järjestelmään ja jaetaan muille järjestelmille dokumentoitujen rajapintojen ja tapahtumien kautta. Tilatapahtumista muodostuu yksi aikajana tilausta kohden. Kun vaihe epäonnistuu tai ylittää toleranssin, agentti kokoaa taustatiedot ja ehdottaa ratkaisua, jonka ihminen hyväksyy, ennen kuin se toteutetaan omistavassa järjestelmässä. Laskut vaihdetaan ja täsmäytetään jäsenneltyinä verkkolaskuina, ja prosessin omistajat seuraavat virtaa ja rajapintojen kuntoa.
Ennen ja jälkeen
Mikä muuttuu päivittäisessä toiminnassa
Nyt
Järjestelmän kanssa
Nyt
Nyt: Uudelleen näppäilyä jokaisessa vaihdossa
Verkkokaupassa tai myyjän ottama tilaus näppäillään uudelleen ERP:hen, ja toimitus- ja laskutustiedot kopioidaan käsin varasto-, kuljetus- ja taloushallinnon järjestelmiin.
Järjestelmän kanssa
Järjestelmän kanssa: Kirjataan kerran, käytetään kaikkialla
Jokainen tilaus, toimitus ja lasku luodaan sen omistavaan järjestelmään ja julkaistaan tapahtumana. Muut järjestelmät tilaavat tapahtuman sen sijaan, että näppäilisivät tiedot uudelleen.
Nyt
Nyt: Eilinen tilanne
Yöllisten eräajojen vuoksi asiakaspalvelu, suunnittelu ja taloushallinto näkevät kukin saman tilauksen eri, vanhentuneessa tilassa. Asiakas, joka kysyy toimituksensa perään, saa takaisinsoiton.
Järjestelmän kanssa
Järjestelmän kanssa: Yksi ajantasainen tila
Jokaisella tilauksella tai pyynnöllä on yksi aikajana, joka muodostuu kaikkien sen läpikulkemien järjestelmien tapahtumista. Asiakaspalvelu, suunnittelu ja taloushallinto katsovat samoja tietoja, kuten myös tilannekysymyksiin vastaava asiakaspalvelun tuki.
Nyt
Nyt: Poikkeukset sähköpostilaatikoissa
Varastopuutteet, hintaerot, epäonnistuneet toimitukset ja hylätyt verkkolaskut selvitetään sähköpostilla ja taulukoissa, eikä jälkikäteen tiedetä, kuka päätti mitäkin.
Järjestelmän kanssa
Järjestelmän kanssa: Poikkeukset saapuvat ehdotuksen kanssa
Agentti kokoaa jokaisen poikkeuksen taustatiedot ja ehdottaa ratkaisua. Ihminen hyväksyy, muokkaa tai hylkää sen yhdessä poikkeusnäkymässä, ja päätös kirjataan.
Nyt
Nyt: Perustiedot, jotka eivät täsmää
Sama asiakas, toimittaja, tuote tai hinta on useassa järjestelmässä eri arvoilla, eikä kukaan vastaa siitä, mikä niistä on oikea.
Järjestelmän kanssa
Järjestelmän kanssa: Yksi omistaja tietokohdetta kohden
Asiakkailla, toimittajilla, tuotteilla ja hinnoilla on kullakin sovittu omistava järjestelmä ja nimetty omistaja. Kaksoiskappaleet ja ristiriidat raportoidaan omistajalle, eikä niitä korjata hiljaa myöhemmissä järjestelmissä.
Nyt
Nyt: Jokainen muutos tuo uuden liittymän
Uusi myyntikanava, markkinapaikka tai yhtiö tarkoittaa uutta suoraa liittymää. Maakohtaiset verkkolaskuvaatimukset lisäävät jokaiseen prosessiin vielä oman muotonsa ja verkkonsa.
Järjestelmän kanssa
Järjestelmän kanssa: Uudet liittymät käyttävät samoja sopimuksia
Uusi kanava, yhtiö tai verkkolaskuverkko liitetään dokumentoituihin rajapintoihin ja tapahtumiin kerran, ei jokaiseen järjestelmään erikseen.
Työnkulku
Näin työnkulku etenee
Kun data on puhdasta, päätyönkulku ei vaadi käsityötä. Kun tilaus, toimitus tai lasku poikkeaa, poikkeussilmukka tuo sen ihmiselle aineiston ja ehdotuksen kanssa, ja hyväksytty korjaus kulkee takaisin saman integraatiokerroksen kautta.
Havainnollistava työnkulku
7 vaihetta · 1 ihmisen tarkistuspiste
Selite
Järjestelmä
Tekoälyagentti
Henkilö
Ihmisen tarkistuspiste
Poikkeuspolku
Yhtenäiset prosessit: havainnollistava työnkulku ja poikkeussilmukka
Lue kaavio tekstinä
Päätyönkulku etenee liiketoimintatapahtuman kirjaamisesta kerran sen omistavaan järjestelmään, jakelusta muille järjestelmille rajapintojen ja tapahtumien kautta ja tilauskohtaisen aikajanan muodostamisesta laskutukseen, täsmäytykseen ja maksuun. Lopuksi prosessin omistajat seuraavat virtaa ja korjaavat poikkeusten syitä.
Kun vaihe epäonnistuu, myöhästyy tai ylittää toleranssin, poikkeus poistuu päätyönkulusta aikajanavaiheen jälkeen. Agentti kokoaa taustatiedot ja ehdottaa ratkaisua, ja ihminen hyväksyy, muokkaa tai hylkää sen. Hyväksytty toimi toteutetaan omistavassa järjestelmässä ja palaa jakeluvaiheeseen uutena tapahtumana.
Hyväksyntävaihe on ihmisen tarkistuspiste: yhtään kirjanpidon kirjausta, hinnan tai luottorajan muutosta tai sitoumusta asiakkaalle ei tehdä ilman ihmistä.
01
Vaihe 1: Tapahtuman kirjaus kerranJärjestelmä
Myyntitilaus verkkokaupasta, markkinapaikalta, EDI:n kautta tai myyjältä, ostotilaus tai palvelupyyntö luodaan sen omistavaan järjestelmään. Järjestelmä julkaisee liiketoimintatapahtuman CloudEvents-kuoressa, ja tapahtuma on kuvattu AsyncAPI-sopimuksessa. Paperilla ja PDF:nä saapuvat tilaukset ja ostolaskut kulkevat ensin asiakirjojen käsittelyn kautta.
02
Vaihe 2: Jakelu rajapintojen ja tapahtumien kauttaJärjestelmä
Integraatiokerros välittää tapahtuman varasto-, kuljetus-, taloushallinto- ja CRM-järjestelmille niiden dokumentoitujen rajapintojen (OpenAPI) kautta. Vastaanottajat ovat idempotentteja, joten toistettu viesti ei koskaan luo toista lähetystä tai laskua, ja perille menemättömät viestit odottavat virhejonossa uudelleenajoa.
03
Vaihe 3: Yksi aikajana tilausta kohdenJärjestelmä
Kaikkien järjestelmien tilatapahtumat (vahvistettu, keräilty, lähetetty, toimitettu, laskutettu, maksettu) yhdistetään liiketoimintaviitteen perusteella yhdeksi aikajanaksi. Virstanpylväs- ja toleranssisäännöt nostavat poikkeuksen, kun vaihe epäonnistuu, myöhästyy tai ei täsmää: varastopuute, sovitun toleranssin ylittävä hinta, epäonnistunut toimitus tai hylätty verkkolasku.
04
Vaihe 4: Taustatiedot ja ehdotusTekoälyagentti
Jokaisen poikkeuksen kohdalla agentti lukee tarvitsemansa tiedot asianomaisista järjestelmistä: tilauksen, varastosaldot, hintasopimuksen, kuljetusliikkeen tilatiedot ja asiakkaan ehdot. Se ehdottaa ratkaisua perusteluineen ja käyttämineen tietoineen, esimerkiksi korvaavaa tuotetta, korjattua hintaa, uutta toimitusaikaa tai korjattua laskua.
Poikkeuspolku: Vaihe epäonnistui tai ylitti toleranssin
05
Vaihe 5: Hyväksyntä raja-arvojen puitteissaHenkilö
Asiakaspalvelun, logistiikan tai taloushallinnon työntekijä näkee poikkeuksen, aineiston ja ehdotuksen poikkeusnäkymässä ja hyväksyy, muokkaa tai hylkää sen. Hyväksytty toimi toteutetaan omistavan järjestelmän rajapinnan kautta, ja järjestelmä julkaisee muutoksen uutena tapahtumana.
Poikkeuspolku: Vaihe epäonnistui tai ylitti toleranssin· Palaa vaiheeseen 2
Ihmisen tarkistuspiste
Agentit eivät koskaan tee kirjanpidon kirjauksia, muuta hintoja tai luottorajoja eivätkä sitoudu asiakkaalle ilman hyväksyntää. Toimityyppikohtaiset raja-arvot ratkaisevat, kuka hyväksyy, ja jokainen ehdotus ja päätös kirjataan.
06
Vaihe 6: Laskutus, täsmäytys ja maksuJärjestelmä
Lähtevät laskut lähtevät ERP:stä jäsenneltyinä verkkolaskuina (Peppol BIS Billing 3.0, EN 16931) yhteyspisteen kautta. Saapuvat ostolaskut täsmäytetään ostotilauksiin ja vastaanottoihin, ja pankin tai maksupalvelun maksutieto sulkee aikajanan.
07
Vaihe 7: Virran seuranta ja syiden korjausHenkilö
Prosessin omistajat ja integraatiotiimi käyvät säännöllisesti läpi poikkeukset syittäin, rajapintojen virheet ja perustietojen ristiriidat. He korjaavat syyn siellä, missä se on, perustietueessa, toleranssisäännössä tai muunnoksessa, sen sijaan että ratkaisisivat saman poikkeuksen yhä uudelleen.
Osat
Mitä rakentaisimme
01
Tapahtumapohjainen integraatiokerros
Sopimus edellä suunnitellut rajapinnat ja tapahtumat ERP:n, CRM:n, verkkokaupan, varaston, kuljetusten ja taloushallinnon välillä, kuvattuina OpenAPI- ja AsyncAPI-muodossa CloudEvents-kuorin, nykyisellä integraatioalustallasi tai pilvinatiivisti rakennettuina.
Sovittu omistava järjestelmä ja omistaja jokaiselle tietokohteelle, täsmäytyssäännöt asiakkaille, toimittajille ja tuotteille sekä raportit kaksoiskappaleista ja ristiriidoista niiden omistajille.
Palvelu, joka yhdistää tapahtumat yhdeksi aikajanaksi tilausta tai pyyntöä kohden, soveltaa virstanpylväs- ja toleranssisääntöjä ja näyttää virran ja poikkeukset prosessin omistajille.
Poikkeusjono, jossa näkyvät kootut taustatiedot ja agentin ehdotus, hyväksy-, muokkaa- ja hylkää-toiminnot sekä toimityyppikohtaiset hyväksyntärajat, jotka valvotaan siinä kohdassa, jossa toimi toteutetaan.
Peppol BIS Billing 3.0- ja EN 16931 -muotoiset UBL-laskut, jotka lähetetään ja vastaanotetaan yhteyspisteen kautta ja tarkistetaan ennen lähettämistä. Hylätyt laskut ohjataan poikkeusnäkymään.
Rajapintakohtainen kunnonvalvonta ja hälytykset, ajo-ohjeet ylläpitotiimille ja epäonnistuneiden viestien hallittu uudelleenajo, otettuna käyttöön infrastruktuuri koodina -periaatteella omassa pilviympäristössäsi.
Kuljetusliikkeiden seuranta- ja toimitustapahtumat
Peppol-verkkolaskut ja tilavastaukset
Tiliotteet ja maksuilmoitukset
Ratkaisun ydin
Yhtenäiset prosessit
Järjestelmät, joihin ratkaisu liittyy
SAP S/4HANA:n myynti, hankinnat ja taloushallintoAlustaSAP
Salesforcen Sales, Service ja Commerce CloudAlustaSalesforce
Odoon myynti, varasto, ostot ja kirjanpitoAlustaOdoo
Verkkokauppa-alustat, markkinapaikat ja kuljetusliikkeiden rajapinnat
Varastonhallinta- ja kuljetustenohjausjärjestelmät
Peppol-yhteyspiste, pankit ja maksupalvelut
Tuotetiedonhallinta ja data-alusta
Hallintakeinot
Sisäänrakennetut hallintakeinot
Käyttöoikeuksien rajat
Jokainen integraatio ja agentti toimii omalla palveluidentiteetillään järjestelmäkohtaisesti, rajattuna tarvitsemiinsa rajapintatoimintoihin. Agentti saa lukea tietoja eri järjestelmistä taustatietojen kokoamiseksi, mutta se voi kirjoittaa vain lyhyen hyväksyttyjen toimien listan kautta, jotka omistavan järjestelmän rajapinta toteuttaa, eikä koskaan suoraan tietokantaan.
Ihmisen tarkastus
Hyväksyntärajat asetetaan toimityypeittäin yhdessä prosessin omistajan kanssa: mitä agentti saa vain ehdottaa, mitä tiimin jäsen hyväksyy ja mihin tarvitaan toinen hyväksyjä. Kirjanpidon kirjaukset, hinta- ja luottorajamuutokset ja sitoumukset asiakkaille odottavat aina ihmistä. Vähäiset ja peruttavissa olevat toimet, kuten epäonnistuneen viestin uudelleenlähetys, voivat toimia ilman hyväksyntää, jos omistaja niin sopii.
Jäljitettävyys
Jokainen tapahtuma, ehdotus, hyväksyntä, hylkäys ja toteutettu toimi kirjataan tilauksen tai pyynnön viitteelle yhdessä agentin käyttämien tietojen, mallin ja kehotteen version sekä hyväksyjän kanssa. Riidanalainen lasku tai asiakkaan reklamaatio voidaan jäljittää vaihe vaiheelta.
Tietosuoja
Asiakkaiden ja toimittajien yhteystiedot kulkevat vain niitä tarvitseviin järjestelmiin. Aikajana tallentaa liiketoimintaviitteet ja tilat eikä kokonaisia tietueita, ja lokit noudattavat asettamaasi säilytysaikaa. Käsittely pysyy sovitulla alueella.
Tekoälyn läpinäkyvyys
Agentin ehdotukset merkitään poikkeusnäkymässä ehdotuksiksi, ja aineisto ja perustelut näytetään niiden vieressä. Omistavat järjestelmät pysyvät määräävinä: aikajana näyttää, mitä ne raportoivat, eikä koskaan ohita niitä.
Mittarit
Mitä mittaisimme
Sovimme mittarit kanssasi esiselvityksen aikana ja otamme lähtötason nykyisistä järjestelmä- ja rajapintalokeista, ennen kuin mitään muutetaan.
Mitä mittaisimme
Mittari
Miksi se on tärkeä
Miten mittaisimme sen
01Tilauksen läpimenoaika
Miksi se on tärkeäMittari, jonka asiakkaat huomaavat ensimmäisenä ja joka näyttää, missä tilaukset odottavat.
Miten mittaisimme senAika tilauksen vastaanotosta toimitukseen ja maksuun kanavittain ja yhtiöittäin aikajanan tapahtumista.
02Tilaukset ilman käsityötä
Miksi se on tärkeäNäyttää, kuinka suuri osa virrasta kulkee puhtaalla datalla ja sovituilla säännöillä.
Miten mittaisimme senNiiden tilausten ja pyyntöjen osuus, jotka etenevät maksuun ilman yhtään käsin tehtyä vaihetta tai poikkeusta, aikajanasta.
03Poikkeukset syittäin ja ratkaisuaika
Miksi se on tärkeäKertoo, mitkä syyt kannattaa korjata ensin ja pysyykö poikkeusnäkymän käsittely tahdissa.
Miten mittaisimme senPoikkeusten määrä syykoodeittain ja aika havaitsemisesta toteutettuun ratkaisuun poikkeusnäkymän lokeista.
04Verkkolaskujen hylkäysaste
Miksi se on tärkeäHylätyt laskut viivästyttävät maksua ja kertovat yleensä perustieto- tai muunnosvirheistä.
Miten mittaisimme senHylättyjen lähetettyjen ja vastaanotettujen verkkolaskujen osuus syittäin yhteyspisteen vastauksista.
05Rajapintojen virheet ja palautumisaika
Miksi se on tärkeäNäyttää, onko integraatiokerros luotettava ja huomataanko ja korjataanko virheet nopeasti.
Miten mittaisimme senEpäonnistuneet viestit rajapinnoittain ja aika virheestä onnistuneeseen uudelleenajoon integraatioiden valvonnasta.
06Perustietojen kaksoiskappaleet ja ristiriidat
Miksi se on tärkeäUseimmat poikkeukset johtuvat tiedoista, jotka eroavat järjestelmien välillä.
Miten mittaisimme senAvoimet kaksoiskappaleet ja ristiriitaiset arvot tietokohteittain ja järjestelmittäin täsmäytysraporteista.
Tavoitteita ei aseteta ennen kuin lähtötaso on mitattu.
Käyttöönotto
Miten ottaisimme sen käyttöön
Vaihe 01
Esiselvitys ja prosessikartta
Yksi prosessi, kuten tilauksesta maksuun yhdessä myyntikanavassa, ja yksi poikkeustyyppi. Kartoitamme järjestelmät, rajapinnat, tietojen omistajat ja sen, miten poikkeukset nyt hoidetaan.
Päättymiskriteerit
Prosessi, järjestelmät ja tietojen omistajat kartoitettu
Ensimmäinen poikkeustyyppi ja hyväksyntärajat sovittu
Lähtötaso otettu nykyisistä lokeista
Vaihe 02
Integraatio ja aikajana
Dokumentoidut rajapinnat ja tapahtumat rajauksen järjestelmille sekä aikajana, joka toimii nykyisten liittymien rinnalla muuttamatta niitä.
Päättymiskriteerit
Tapahtumasopimukset julkaistu ja versioitu
Aikajana vastaa omistavia järjestelmiä tilausotoksessa
Uudelleenajo ja ajo-ohjeet testattu
Vaihe 03
Poikkeusnäkymän pilotti
Agentti ehdottaa ratkaisuja valitulle poikkeustyypille, ja ihmiset hyväksyvät jokaisen ehdotuksen. Vertaamme ehdotuksia siihen, mitä henkilöstö olisi tehnyt.
Päättymiskriteerit
Ehdotusten laatu täyttää sovitut kriteerit
Raja-arvot ja hyväksyjät asetettu toimityypeittäin
Taloushallinto ja sisäinen valvonta ovat käyneet kirjausketjun läpi
Vaihe 04
Laajennus ja vanhan purku
Lisää poikkeustyyppejä, kanavia, yhtiöitä ja prosesseja, kuten hankinnasta maksuun, kaikki samoilla sopimuksilla. Vanhat suorat liittymät sammutetaan yksi kerrallaan.
Päättymiskriteerit
Jokainen uusi virta samoilla sopimuksilla ja samassa valvonnassa
Elintarvike-, elektroniikka- ja muoviteollisuuden tilaukset ERP:stä varastoon ja kuljetusliikkeille, toimittajien vahvistukset ja verkkolaskut täsmäytettyinä ostotilauksiin.
Hankinnasta maksuun EN 16931 -muotoisin verkkolaskuin hyvinvointialueilla, kunnissa ja valtion virastoissa, laskut täsmäytettyinä tilauksiin ja vastaanottoihin ennen maksua.
Havainnollistava esimerkki
Tukkukauppa Suomessa, Ruotsissa ja Virossa
Tilanne
Teknisen tukkukaupan tuotteita myydään verkkokaupassa, kahdella markkinapaikalla ja kenttämyynnin kautta Suomessa, Ruotsissa ja Virossa kahdesta varastosta. Tilaukset näppäillään uudelleen ERP:hen, kuljetusliikkeet ilmoittavat toimitusongelmista sähköpostilla, ja jokainen maa laskuttaa omalla tavallaan.
Järjestelmä
Tilaukset, saldot, lähetykset ja laskut kulkevat tapahtumina verkkokaupan, ERP:n, varastojärjestelmän ja kuljetusliikkeiden välillä, ja jokaisella tilauksella on yksi aikajana. Laskut lähtevät jäsenneltyinä verkkolaskuina yhden yhteyspisteen kautta kunkin maan edellyttämässä verkossa ja muodossa, Suomen julkisille asiakkaille EN 16931 -muodossa.
Ihmisen ohjaus
Varastopuutteet ja epäonnistuneet toimitukset tulevat yhteen poikkeusnäkymään, jossa agentti ehdottaa korvaavaa tuotetta tai uutta toimitusaikaa. Asiakaspalvelu hyväksyy jokaisen ehdotuksen, ja hinnanmuutokset ja hyvityslaskut vaativat taloushallinnon hyväksynnän.
Mitä mittaisimme
Ilman käsityötä kulkevien tilausten osuus maittain ja kanavittain, poikkeukset syittäin ja ratkaisuaika sekä verkkolaskujen hylkäysaste maittain.
Suomi
Yksi prosessi, monta maata ja vaatimusta
Suomessa verkkolaskutus on vakiintunutta, ja julkiset hankintayksiköt voivat sähköisestä laskutuksesta annetun lain (241/2019) nojalla vaatia toimittajilta EN 16931 -muotoisia laskuja. Sähköpostitse lähetetty PDF ei ole verkkolasku. Ulkomaiset toimittajat voivat lähettää verkkolaskuja valtiolle Peppolin kautta, ja Suomen Peppol-viranomaisena toimii Valtiokonttori.
Pohjoismaissa ja muualla EU:ssa toimivat yritykset ajavat usein samoja tilauksesta maksuun ja hankinnasta maksuun -prosesseja eri ERP-instansseilla, kuljetusliikkeillä ja pankeilla. Kansalliset verkkolaskuvaatimukset tulevat voimaan eri aikoina, ja EU:n digiajan lainsäädäntöpaketti ViDA tekee jäsennellystä verkkolaskutuksesta oletuksen EU:n sisäisissä yritysten välisissä myynneissä 1. heinäkuuta 2030 alkaen. Suunnittelemme yhden integraatiokerroksen, jossa kunkin maan muoto ja verkko ovat samojen tapahtumien takana, joten uusi vaatimus tarkoittaa uutta liittymää eikä uutta prosessia.
Datasäädöksen palveluntarjoajan vaihtamista koskevia sääntöjä on sovellettu 12. syyskuuta 2025 alkaen, joten pidämme tapahtumasopimukset ja datan viennit siirrettävinä. Poikkeusnäkymän agentit suunnitellaan tekoälysäädöksen mukaan. Integraatioissa on kirjatut käyttöoikeudet ja dokumentoidut osat asiakkaille, joiden on osoitettava toimitusketjun tietoturva kyberturvallisuuslain mukaisesti.
Ei. ERP, CRM, verkkokauppa ja varastonhallinta hoitavat kukin oman tehtävänsä. Integroimme näiden omistavien järjestelmien ympärille, sovimme, mikä järjestelmä omistaa mitkäkin tiedot, ja annamme prosessille yhden aikajanan niiden yli. Jos vanha tilaus- tai ERP-järjestelmä estää muutoksen, vanhojen järjestelmien uudistus vie sen ensin rajapintojen taakse.
02Korvaatteko nykyisen integraatioalustamme?
Emme, jos se hoitaa tehtävänsä. Rakennamme jo käytössä olevan integraatioalustan tai viestinvälittäjän päälle ja lisäämme sopimukset, valvonnan ja uudelleenajon siellä, missä ne puuttuvat. Jos alustaa ei ole, rakennamme pilvinatiivisti. Lue lisää palvelusta Integraatiot & rajapinnat.
03Voivatko agentit toimia itsenäisesti?
Vain toimityypeittäin sovittujen raja-arvojen puitteissa ja vain vähäisissä, peruttavissa olevissa toimissa, kuten epäonnistuneen viestin uudelleenlähetyksessä. Kirjanpidon kirjaukset, hinnat, luottorajat ja sitoumukset asiakkaille vaativat aina ihmisen. Lue, missä tekoälyagentit tarvitsevat ihmisen hyväksynnän.
04Miten verkkolaskuvaatimukset sopivat tähän?
Suomessa verkkolasku on jo arkea. Laki sähköisestä laskutuksesta (241/2019) antaa hankintayksiköille oikeuden vaatia EN 16931 -muotoisia sähköisiä laskuja, ja ulkomaiset toimittajat voivat laskuttaa valtiota Peppolin kautta. Muissa maissa vaatimukset tulevat voimaan eri aikoina, ja EU:n digiajan lainsäädäntöpaketti ViDA tekee jäsennellystä verkkolaskutuksesta oletuksen EU:n sisäisissä yritysten välisissä myynneissä 1. heinäkuuta 2030 alkaen. Käsittelemme verkkolaskua yhtenä prosessin tapahtumana: se lähtee ERP:stä, kulkee yhteyspisteen kautta ja käsitellään poikkeusnäkymässä, jos se hylätään. Lue oppaamme Peppol-verkkolaskutukseen.
05Miten vältätte uuden hauraan suorien liittymien verkon?
Järjestelmät julkaisevat ja käyttävät dokumentoituja tapahtumia ja rajapintoja yhden kerroksen kautta, eivät suorilla liittymillä toisiinsa. Sopimukset versioidaan, vastaanottajat ovat idempotentteja, epäonnistuneet viestit voidaan ajaa uudelleen, ja jokaisella virralla on nimetty omistaja. Uusi kanava tilaa olemassa olevat tapahtumat sen sijaan, että siitä rakennettaisiin liittymä jokaiseen järjestelmään.
06Miltä ensimmäinen laajuus näyttää?
Yksi prosessi ja yksi poikkeustyyppi, esimerkiksi tilauksesta maksuun yhdessä myyntikanavassa ja varastopuutteet ensimmäisenä poikkeuksena. Se todentaa tapahtumat, aikajanan ja hyväksyntävirran, ennen kuin laajuutta kasvatetaan. Lue lisää toimintatavastamme.
Kerro tilaus- ja laskuvirroistasi
Valitse yksi prosessi ja maat, joissa se toimii. Kartoitamme järjestelmät, rajapinnat ja poikkeukset kanssasi ja ehdotamme ensimmäistä julkaisua, joka toimii kaikissa yhtiöissäsi.