Každá objednávka na jednej časovej osi, od prijatia po zaplatenú faktúru.
Order to cash, procure to pay a cesta od servisnej požiadavky po faktúru prechádzajú cez ERP, CRM, e-shop, skladový, dopravný a účtovný systém. Prepájame ich zdokumentovanými API a udalosťami, každej objednávke dáme jeden stav naprieč týmito systémami a každú výnimku pošleme agentovi, ktorý pripraví riešenie na schválenie človekom.
Pre firmy na Slovensku, ktoré predávajú, nakupujú a fakturujú aj v ďalších krajinách EÚ, každá s vlastnými systémami, dopravcami a pravidlami e-fakturácie.
Objednávka, nákupná objednávka alebo servisná požiadavka sa zaznamená raz vo svojom zdrojovom systéme a do ostatných systémov sa rozošle cez zdokumentované API a udalosti. Udalosti o stave vytvoria pre každú objednávku jednu časovú os. Keď krok zlyhá alebo vybočí z tolerancie, agent zhromaždí kontext a navrhne riešenie, ktoré človek schváli skôr, než sa vykoná v zdrojovom systéme. Faktúry sa vymieňajú a párujú ako štruktúrované e-faktúry a vlastníci procesov sledujú tok a stav rozhraní.
Pred a po
Čo sa zmení v každodennej prevádzke
Dnes
So systémom
Dnes
Dnes: Pri každom odovzdaní sa znova prepisuje
Objednávka z e-shopu alebo od obchodníka sa znova zadá do ERP a údaje o dodávke a faktúre sa ručne prepisujú do skladového, dopravného a účtovného systému.
So systémom
So systémom: Zadané raz, použité všade
Každá objednávka, dodávka a faktúra vznikne v systéme, ktorý ju vlastní, a zverejní sa ako udalosť. Ostatné systémy ju odoberajú namiesto toho, aby ju prepisovali.
Dnes
Dnes: Včerajší stav
Pre nočné dávkové rozhrania vidí zákaznícky servis, plánovanie aj účtovníctvo iný, zastaraný stav tej istej objednávky. Zákazník, ktorý sa pýta, kde je dodávka, sa dočká spätného zavolania.
So systémom
So systémom: Jeden aktuálny stav
Každá objednávka alebo požiadavka má jednu časovú os zostavenú z udalostí všetkých systémov, ktorými prechádza. Zákaznícky servis, plánovanie aj účtovníctvo sa pozerajú na tie isté fakty a rovnako aj asistent podpory, ktorý odpovedá na otázky o stave.
Dnes
Dnes: Výnimky sa riešia v e-mailoch
Nedostatok zásob, nezhody v cenách, nedoručené zásielky a odmietnuté e-faktúry sa riešia e-mailom a v tabuľkách a dodatočne nikto nevie povedať, kto o čom rozhodol.
So systémom
So systémom: Výnimky prichádzajú s návrhom
Agent zhromaždí údaje za každou výnimkou a navrhne riešenie. Človek ho na jednom pracovisku výnimiek schváli, upraví alebo odmietne a rozhodnutie sa zaznamená.
Dnes
Dnes: Kmeňové dáta, ktoré si odporujú
Ten istý zákazník, dodávateľ, výrobok alebo cena existuje vo viacerých systémoch s rôznymi hodnotami a nikto nezodpovedá za to, ktorá je správna.
So systémom
So systémom: Jeden vlastník pre každý dátový objekt
Zákazníci, dodávatelia, výrobky a ceny majú dohodnutý zdrojový systém a menovitého vlastníka. Duplicity a rozpory sa hlásia tomuto vlastníkovi, nie potichu opravujú v nadväzujúcich systémoch.
Dnes
Dnes: Každá zmena pridá rozhranie
Nový predajný kanál, marketplace alebo spoločnosť v skupine znamená ďalšie prepojenie bod-bod. Národné povinnosti elektronickej fakturácie k tomu do každého procesu pridávajú štruktúrovaný formát a sieť.
So systémom
So systémom: Nové prepojenia využívajú tie isté kontrakty
Nový kanál, spoločnosť alebo sieť pre e-faktúry sa napojí na zdokumentované API a udalosti raz, nie na každý systém zvlášť.
Pracovný postup
Ako pracovný postup prebieha
Keď sú dáta čisté, hlavná cesta nepotrebuje ručnú prácu. Keď sa objednávka, dodávka alebo faktúra odchýli, slučka výnimiek ju prinesie človeku s podkladmi a návrhom a schválená oprava sa vráti cez tú istú integračnú vrstvu.
Ilustračný pracovný postup
7 krokov · 1 kontrola človekom
Legenda
Systém
AI agent
Človek
Kontrola človekom
Postup pri výnimke
Prepojené procesy: ilustračný pracovný postup so slučkou výnimiek
Prečítať diagram ako text
Hlavná cesta vedie od jednorazového zaznamenania obchodnej udalosti v zdrojovom systéme cez jej rozoslanie do ostatných systémov pomocou API a udalostí a zostavenie jednej časovej osi pre objednávku k fakturácii, párovaniu a úhrade. Končí tým, že vlastníci procesov kontrolujú tok a odstraňujú príčiny výnimiek.
Keď krok zlyhá, mešká alebo vybočí z tolerancie, výnimka opustí hlavnú cestu po kroku časovej osi. Agent zhromaždí kontext a navrhne riešenie a človek ho schváli, upraví alebo odmietne. Schválený krok sa vykoná v zdrojovom systéme a vráti sa do kroku rozoslania ako nová udalosť.
Krok schválenia je kontrolný bod človeka: bez človeka sa neúčtuje, nemení sa cena ani úverový limit a zákazníkovi sa nič nesľúbi.
01
Krok 1: Udalosť sa zaznamená razSystém
Predajná objednávka z e-shopu, marketplace, EDI alebo od obchodníka, nákupná objednávka či servisná požiadavka vznikne v systéme, ktorý ju vlastní. Ten zverejní obchodnú udalosť v obálke CloudEvents, opísanú v kontrakte AsyncAPI. Papierové a PDF objednávky a faktúry dodávateľov najprv prejdú spracovaním dokumentov.
02
Krok 2: Rozoslanie cez API a udalostiSystém
Integračná vrstva doručí udalosť do skladového, dopravného, účtovného a CRM systému cez ich zdokumentované API (OpenAPI). Príjemcovia sú idempotentní, takže opakovaná správa nikdy nevytvorí druhú zásielku ani faktúru, a správy, ktoré sa nedajú doručiť, čakajú v chybovom fronte na opätovné spracovanie.
03
Krok 3: Jedna časová os pre objednávkuSystém
Udalosti o stave zo všetkých systémov (potvrdená, vychystaná, odoslaná, doručená, vyfakturovaná, zaplatená) sa podľa obchodnej referencie spoja do jednej časovej osi. Pravidlá míľnikov a tolerancií vytvoria výnimku, keď krok zlyhá, mešká alebo nesedí: nedostatok zásob, cena mimo dohodnutej tolerancie, nedoručená zásielka, odmietnutá e-faktúra.
04
Krok 4: Zber kontextu a návrhAI agent
Pri každej výnimke si agent z dotknutých systémov prečíta, čo potrebuje: objednávku, stav zásob, cenovú dohodu, stav u dopravcu a podmienky zákazníka. Navrhne riešenie so zdôvodnením a použitými údajmi, napríklad náhradnú položku, opravenú cenu, nový termín dodania alebo opravnú faktúru.
Postup pri výnimke: Krok zlyhal alebo je mimo tolerancie
05
Krok 5: Schválenie v rámci limitovČlovek
Pracovník zákazníckeho servisu, logistiky alebo účtovníctva vidí na pracovisku výnimiek výnimku, podklady a návrh a schváli ho, upraví alebo odmietne. Schválený krok sa vykoná cez API zdrojového systému, ktorý zmenu zverejní ako novú udalosť.
Postup pri výnimke: Krok zlyhal alebo je mimo tolerancie· Vracia sa ku kroku 2
Kontrola človekom
Agenti nikdy bez schválenia neúčtujú finančné transakcie, nemenia ceny ani úverové limity a nič nesľubujú zákazníkovi. O tom, kto schvaľuje, rozhodujú limity pre každý typ kroku a každý návrh aj rozhodnutie sa zaznamenajú.
06
Krok 6: Fakturácia, párovanie a úhradaSystém
Vystavené faktúry odchádzajú z ERP ako štruktúrované e-faktúry (Peppol BIS Billing 3.0, EN 16931) cez prístupový bod. Prijaté faktúry dodávateľov sa spárujú s nákupnými objednávkami a príjemkami a stav platby z banky alebo od platobného poskytovateľa časovú os uzavrie.
07
Krok 7: Kontrola toku a odstránenie príčinČlovek
Vlastníci procesov a integračný tím v pevnom rytme prechádzajú výnimky podľa dôvodu, zlyhania rozhraní a rozpory v kmeňových dátach. Príčinu odstránia tam, kde vzniká, v kmeňovom zázname, pravidle tolerancie alebo mapovaní, namiesto toho, aby tú istú výnimku riešili znova.
Komponenty
Čo by sme postavili
01
Integračná vrstva riadená udalosťami
API a udalosti navrhnuté od kontraktu medzi ERP, CRM, e-shopom, skladom, dopravou a financiami, opísané v OpenAPI a AsyncAPI s obálkami CloudEvents, na vašej existujúcej integračnej platforme alebo postavené natívne v cloude.
Dohodnutý zdrojový systém a vlastník pre každý dátový objekt, pravidlá párovania zákazníkov, dodávateľov a výrobkov a správy o duplicitách a rozporoch pre ľudí, ktorí za ne zodpovedajú.
Služba, ktorá spája udalosti do jednej časovej osi pre každú objednávku alebo požiadavku, uplatňuje pravidlá míľnikov a tolerancií a vlastníkom procesov ukazuje tok a výnimky.
Front výnimiek so zhromaždeným kontextom a návrhom agenta, s krokmi schváliť, upraviť a odmietnuť a s limitmi schvaľovania pre každý typ kroku, vynútenými tam, kde sa krok vykonáva.
Faktúry podľa Peppol BIS Billing 3.0 a EN 16931 vo formáte UBL, posielané a prijímané cez prístupový bod, overené pred odoslaním, s odmietnutými faktúrami presmerovanými na pracovisko výnimiek.
Monitorovanie stavu a upozornenia pre každé rozhranie, prevádzkové príručky pre prevádzkový tím a riadené opätovné spracovanie neúspešných správ, nasadené ako infraštruktúra ako kód vo vašom cloudovom prostredí.
Salesforce Sales, Service a Commerce CloudPlatformaSalesforce
Odoo, predaj, sklad, nákup a účtovníctvoPlatformaOdoo
E-commerce platformy, marketplace a API dopravcov
Systémy riadenia skladu a dopravy
Prístupový bod Peppol, banky a platobní poskytovatelia
Správa produktových informácií a dátová platforma
Kontrolné mechanizmy
Zabudované kontrolné mechanizmy
Hranice prístupu
Každá integrácia aj agent bežia v každom systéme pod vlastnou servisnou identitou, obmedzenou na operácie API, ktoré potrebujú. Agent smie na zber kontextu čítať naprieč systémami, ale zapisovať môže len cez krátky zoznam schválených krokov, ktoré vykoná API zdrojového systému, nikdy priamym prístupom do databázy.
Kontrola človekom
Limity schvaľovania sa nastavujú pre každý typ kroku spolu s vlastníkom procesu: čo smie agent len navrhnúť, čo schváli člen tímu a čo potrebuje druhého schvaľovateľa. Účtovanie, zmeny cien a úverových limitov a záväzky voči zákazníkom vždy čakajú na človeka. Kroky s malým dosahom, ktoré sa dajú vrátiť, napríklad opakovanie neúspešnej správy, môžu bežať bez schválenia, ak s tým vlastník súhlasí.
Auditovateľnosť
Každá udalosť, návrh, schválenie, odmietnutie a vykonaný krok sa zaznamená k referencii objednávky alebo požiadavky, s údajmi, ktoré agent použil, verziou modelu a promptu a schvaľovateľom. Spornú faktúru alebo reklamáciu zákazníka sa dá dohľadať krok za krokom.
Ochrana údajov
Kontaktné údaje zákazníkov a dodávateľov prúdia len do systémov, ktoré ich potrebujú. Časová os uchováva obchodné referencie a stavy, nie celé záznamy, a záznamy sa uchovávajú podľa vami určenej doby. Spracúvanie zostáva v dohodnutom regióne.
Transparentnosť AI
Návrhy agenta sú na pracovisku výnimiek takto označené a vedľa nich sa zobrazujú podklady a zdôvodnenie. Zdrojové systémy zostávajú rozhodujúce: časová os ukazuje, čo hlásia, a nikdy ich neprepisuje.
Ukazovatele
Čo by sme merali
Ukazovatele dohodneme s vami počas úvodnej analýzy a východiskový stav vezmeme zo záznamov vašich súčasných systémov a rozhraní, ešte pred akoukoľvek zmenou.
Čo by sme merali
Ukazovateľ
Prečo je dôležitý
Ako by sme ho merali
01Doba cyklu objednávky
Prečo je dôležitýUkazovateľ, ktorý zákazníci vnímajú ako prvý a ktorý ukazuje, kde objednávky čakajú.
Ako by sme ho meraliČas od prijatia objednávky po dodanie a po úhradu, podľa kanála a spoločnosti, z udalostí časovej osi.
02Objednávky bez ručného zásahu
Prečo je dôležitýUkazuje, aká časť toku beží na čistých dátach a dohodnutých pravidlách.
Ako by sme ho meraliPodiel objednávok a požiadaviek, ktoré sa dostanú po úhradu bez ručného kroku či výnimky, z časovej osi.
03Výnimky podľa dôvodu a čas vyriešenia
Prečo je dôležitýUkáže, ktoré príčiny odstrániť ako prvé a či pracovisko výnimiek stíha.
Ako by sme ho meraliObjem výnimiek podľa kódu dôvodu a čas od zistenia po vykonané riešenie, zo záznamov pracoviska výnimiek.
04Podiel odmietnutých e-faktúr
Prečo je dôležitýOdmietnuté faktúry odďaľujú platbu a zvyčajne ukazujú na chyby v kmeňových dátach alebo mapovaní.
Ako by sme ho meraliPodiel odoslaných a prijatých e-faktúr, ktoré boli odmietnuté, podľa dôvodu, z odpovedí prístupového bodu.
05Zlyhania rozhraní a čas obnovy
Prečo je dôležitýUkazuje, či je integračná vrstva spoľahlivá a či sa zlyhania rýchlo zistia a odstránia.
Ako by sme ho meraliNeúspešné správy pre každé rozhranie a čas od zlyhania po úspešné opätovné spracovanie, z monitorovania integrácií.
06Duplicity a rozpory v kmeňových dátach
Prečo je dôležitýVäčšina výnimiek má pôvod v dátach, ktoré sa v jednotlivých systémoch líšia.
Ako by sme ho meraliOtvorené duplicity a rozdielne hodnoty pre každý dátový objekt a systém, zo správ o párovaní.
Cieľové hodnoty nestanovujeme, kým nie je známy východiskový stav.
Zavedenie
Ako by sme riešenie zaviedli
Fáza 01
Úvodná analýza a mapa procesu
Jeden proces, napríklad order to cash pre jeden predajný kanál, a jeden typ výnimky. Zmapujeme systémy, rozhrania, vlastníkov dát a dnešný spôsob riešenia výnimiek.
Kritériá ukončenia
Proces, systémy a vlastníci dát zmapovaní
Prvý typ výnimky a limity schvaľovania dohodnuté
Východiskový stav zo súčasných záznamov
Fáza 02
Integrácia a časová os
Zdokumentované API a udalosti pre systémy v rozsahu a časová os, ktorá beží popri existujúcich rozhraniach bez toho, aby ich menila.
Kritériá ukončenia
Kontrakty udalostí zverejnené a verzované
Časová os sa na vzorke objednávok zhoduje so zdrojovými systémami
Opätovné spracovanie a prevádzkové príručky otestované
Fáza 03
Pilot pracoviska výnimiek
Agent navrhuje riešenia pre vybraný typ výnimky a ľudia schvaľujú každý návrh. Návrhy porovnávame s tým, čo by urobili pracovníci.
Kritériá ukončenia
Kvalita návrhov spĺňa dohodnuté kritériá
Limity a schvaľovatelia určení pre každý typ kroku
Auditnú stopu skontrolovalo účtovníctvo a interná kontrola
Fáza 04
Rozšírenie a vyradenie
Ďalšie typy výnimiek, kanály, spoločnosti a procesy, napríklad procure to pay, každý na tých istých kontraktoch. Staré prepojenia bod-bod sa vypínajú jedno po druhom.
Kritériá ukončenia
Každý nový tok na tých istých kontraktoch a monitorovaní
Zákazková výroba a objednávky náhradných dielov od ERP po sklad a dopravcov, s potvrdeniami dodávateľov a e-faktúrami spárovanými s nákupnými objednávkami.
Objednávky servisu a náhradných dielov pre vozidlá mestskej hromadnej dopravy alebo regionálneho autobusového dopravcu a faktúry k nim, sledované od požiadavky po platbu.
Procure to pay so štruktúrovanými e-faktúrami, ktoré verejní obstarávatelia musia od 1. januára 2027 vedieť prijímať, spárovanými s objednávkami a príjemkami pred úhradou.
Ilustračný príklad
Order to cash u dodávateľa pre automobilový priemysel
Situácia
Dodávateľ plastových dielov pre automobilový priemysel má závody na Slovensku a v Česku a dodáva odberateľom v niekoľkých krajinách. Odvolávky prichádzajú cez EDI aj e-mailom, dopravcovia hlásia problémy telefonicky a od 1. januára 2027 musia tuzemské faktúry odchádzať ako štruktúrované e-faktúry.
Systém
Odvolávky, zásoby, expedície a faktúry tečú ako udalosti medzi EDI, ERP, skladovým systémom a dopravcami a každá objednávka má jednu časovú os. Tuzemské faktúry odchádzajú cez certifikovaného poskytovateľa v sieti Peppol, ostatné vo formáte a sieti, ktoré vyžaduje krajina odberateľa.
Rozhoduje človek
Nedostatok materiálu a oneskorené expedície sa dostanú na jedno pracovisko výnimiek, kde agent navrhne nový termín alebo rozdelenie dodávky. Každý návrh schvaľuje logistika; zmeny cien a dobropisy schvaľuje finančné oddelenie.
Čo by sme merali
Podiel objednávok bez ručného zásahu podľa závodu a odberateľa, výnimky podľa dôvodu a času vyriešenia a podiel odmietnutých e-faktúr podľa krajiny.
Slovensko
Jeden proces, slovenská e-faktúra a ďalšie krajiny
Od 1. januára 2027 musí každá zdaniteľná osoba v tuzemsku vedieť prijímať e-faktúry cez Peppol a tuzemské faktúry B2B a B2G odchádzajú v štruktúrovanej podobe podľa EN 16931 cez certifikovaných poskytovateľov, s vykazovaním údajov Finančnej správe. Mnohé firmy na Slovensku pritom patria do skupín so spoločnosťami v susedných krajinách, kde platia iné termíny a formáty, a balík EÚ o DPH pre digitálny vek robí zo štruktúrovanej e-faktúry od 1. júla 2030 štandard pre dodania B2B v rámci EÚ. Navrhujeme jednu integračnú vrstvu, v ktorej formát a sieť každej krajiny stoja za tými istými udalosťami, takže nová povinnosť znamená nový konektor, nie nový proces.
Akt o údajoch, ktorý sa uplatňuje od 12. septembra 2025, stanovuje pravidlá zmeny poskytovateľa služieb spracúvania údajov, preto držíme kontrakty udalostí a exporty dát prenositeľné. Agenti na pracovisku výnimiek sú navrhnutí s ohľadom na akt o umelej inteligencii a integrácie prinášajú zaznamenaný prístup a zdokumentované komponenty pre zákazníkov, ktorí musia podľa zákona o kybernetickej bezpečnosti preukázať bezpečnosť dodávateľského reťazca.
Nie. Vaše ERP, CRM, e-shop a skladový systém robia každý svoju prácu. Integrujeme okolo týchto zdrojových systémov, dohodneme, ktorý systém vlastní ktoré dáta, a procesu dáme jednu časovú os naprieč nimi. Ak zmenu blokuje starý objednávkový alebo ERP systém, modernizácia starších systémov ho najprv schová za API.
02Nahradíte náš integračný middleware?
Nie, ak plní svoju úlohu. Staviame na integračnej platforme alebo message brokeri, ktoré už prevádzkujete, a dopĺňame kontrakty, monitorovanie a opätovné spracovanie tam, kde chýbajú. Ak žiadne nemáte, staviame natívne v cloude. Viac o našej integračnej práci.
03Môžu agenti konať samostatne?
Len v rámci limitov, ktoré dohodnete pre každý typ kroku, a len pri krokoch s malým dosahom, ktoré sa dajú vrátiť, napríklad pri opakovaní neúspešnej správy. Účtovanie, ceny, úverové limity a záväzky voči zákazníkom vždy potrebujú človeka. Prečítajte si, kde AI agenti potrebujú schválenie človekom.
04Ako sem zapadá povinná elektronická fakturácia?
Na Slovensku platí od 1. januára 2027 povinná štruktúrovaná fakturácia pre tuzemské transakcie B2B a B2G: faktúry podľa EN 16931 idú cez certifikovaných poskytovateľov v sieti Peppol s vykazovaním údajov Finančnej správe a prijímať ich musí vedieť každá zdaniteľná osoba v tuzemsku. Iné krajiny zavádzajú vlastné povinnosti v iných termínoch a balík EÚ o DPH pre digitálny vek robí zo štruktúrovanej e-faktúry od 1. júla 2030 štandard pre dodania B2B v rámci EÚ. E-faktúru preto považujeme za ďalšiu udalosť v procese: vystaví ju ERP, odíde cez prístupový bod a pri odmietnutí sa rieši na pracovisku výnimiek. Pozrite si náš prehľad elektronickej fakturácie cez Peppol.
05Ako sa vyhnete ďalšej krehkej sieti prepojení bod-bod?
Systémy zverejňujú a odoberajú zdokumentované udalosti a API cez jednu vrstvu, nie cez priame prepojenia medzi sebou. Kontrakty sú verzované, príjemcovia idempotentní, neúspešné správy sa dajú spracovať znova a každý tok má menovitého vlastníka. Nový kanál sa prihlási na odber existujúcich udalostí namiesto toho, aby pridal prepojenie na každý systém.
06Ako vyzerá prvý rozsah?
Jeden proces a jeden typ výnimky, napríklad order to cash pre jeden predajný kanál s nedostatkom zásob ako prvou výnimkou. Overí udalosti, časovú os a schvaľovanie skôr, než pribudne ďalšie. Prečítajte si o našom spôsobe dodávky.
Prediskutujme vaše toky objednávok a faktúr
Vyberte jeden proces a krajiny, v ktorých beží. Spolu zmapujeme systémy, rozhrania a výnimky a navrhneme prvé vydanie, ktoré funguje naprieč vašimi spoločnosťami.