Každá objednávka na jedné časové ose, od přijetí po zaplacenou fakturu.
Procesy od objednávky po úhradu, od nákupu po platbu a od servisního požadavku po fakturu procházejí ERP, CRM, e-shopem, skladem, dopravou a účetnictvím. Propojíme je zdokumentovanými API a událostmi, každé objednávce dáme jeden stav napříč těmito systémy a každou výjimku pošleme agentovi, který připraví řešení ke schválení člověkem.
Pro firmy v Česku, které prodávají, nakupují a fakturují i v Německu nebo na Slovensku, kde má každá země vlastní systémy, dopravce a pravidla pro faktury.
Objednávka, nákupní objednávka nebo servisní požadavek se zaznamená jednou v systému, který je za ni odpovědný, a do ostatních systémů se rozešle přes zdokumentovaná API a události. Ze stavových událostí vzniká jedna časová osa pro každou objednávku. Když krok selže nebo vybočí z tolerance, agent shromáždí kontext a navrhne řešení, které člověk schválí dřív, než se provede v odpovědném systému. Faktury se vyměňují a párují jako strukturované e-faktury a vlastníci procesů sledují tok i stav rozhraní.
Před a po
Co se změní v každodenním provozu
Dnes
Se systémem
Dnes
Dnes: Přepisování při každém předání
Objednávka z e-shopu nebo od obchodníků se znovu zadává do ERP a údaje o dodávce a faktuře se ručně kopírují do skladového, dopravního a účetního systému.
Se systémem
Se systémem: Zadáno jednou, použito všude
Každá objednávka, dodávka a faktura vzniká v systému, který je za ni odpovědný, a ten ji zveřejní jako událost. Ostatní systémy ji odebírají, místo aby ji přepisovaly.
Dnes
Dnes: Včerejší stav
Kvůli nočním dávkovým rozhraním vidí zákaznický servis, plánování a účtárna každý jiný, zastaralý stav téže objednávky. Zákazník, který se ptá, kde je dodávka, čeká na zpětné zavolání.
Se systémem
Se systémem: Jeden aktuální stav
Každá objednávka nebo požadavek má jednu časovou osu složenou z událostí všech systémů, kterými prochází. Zákaznický servis, plánování a účtárna vidí stejná fakta a stejně tak asistent klientské péče, který odpovídá na dotazy ke stavu.
Dnes
Dnes: Výjimky v e-mailových schránkách
Nedostatek zásob, neshody v cenách, nedoručené zásilky a odmítnuté e-faktury se řeší e-mailem a v tabulkách a nikdo pak neřekne, kdo co rozhodl.
Se systémem
Se systémem: Výjimky přicházejí s návrhem
Agent ke každé výjimce shromáždí potřebná data a navrhne řešení. Člověk ho na jednom pracovišti pro výjimky schválí, upraví nebo odmítne a rozhodnutí se zaznamená.
Dnes
Dnes: Kmenová data, která si odporují
Stejný odběratel, dodavatel, produkt nebo cena existuje v několika systémech s různými hodnotami a nikdo neodpovídá za to, která je správná.
Se systémem
Se systémem: Jeden vlastník pro každý datový objekt
Odběratelé, dodavatelé, produkty a ceny mají dohodnutý odpovědný systém a jmenovitého vlastníka. Duplicity a rozpory se hlásí tomuto vlastníkovi, ne tiše opravují v navazujících systémech.
Dnes
Dnes: Každá změna přidá rozhraní
Nový prodejní kanál, tržiště nebo společnost ve skupině znamená další propojení bod s bodem. Navíc každý odběratel chce faktury jinak: PDF e-mailem, ISDOC, Peppol nebo vlastní portál.
Se systémem
Se systémem: Nová napojení využívají stejné kontrakty
Nový kanál, společnost nebo síť pro e-fakturaci se napojí jednou na zdokumentovaná API a události, ne na každý systém zvlášť.
Pracovní postup
Jak pracovní postup probíhá
Když jsou data čistá, hlavní cesta nepotřebuje žádnou ruční práci. Když se objednávka, dodávka nebo faktura odchýlí, smyčka výjimek ji přinese člověku i s podklady a návrhem a schválená oprava proteče zpět stejnou integrační vrstvou.
Ilustrativní pracovní postup
7 kroků · 1 kontrola člověkem
Legenda
Systém
AI agent
Člověk
Kontrola člověkem
Postup při výjimce
Propojené procesy: ilustrativní pracovní postup se smyčkou výjimek
Zobrazit diagram jako text
Hlavní cesta vede od jednorázového záznamu obchodní události v odpovědném systému přes její rozeslání do ostatních systémů pomocí API a událostí a sestavení časové osy objednávky až k fakturaci, párování a úhradě. Končí tím, že vlastníci procesů zrevidují tok a odstraní příčiny výjimek.
Když krok selže, zpozdí se nebo vybočí z tolerance, opustí výjimka hlavní cestu po kroku časové osy. Agent shromáždí kontext a navrhne řešení a člověk ho schválí, upraví nebo odmítne. Schválený krok se provede v odpovědném systému a jako nová událost se vrací ke kroku rozeslání.
Krok schválení je kontrola člověkem: bez člověka nevznikne žádné finanční zaúčtování, změna ceny nebo úvěrového limitu ani závazek vůči zákazníkovi.
01
Krok 1: Událost zaznamenaná jednouSystém
Prodejní objednávka z e-shopu, tržiště, EDI nebo od obchodníků, nákupní objednávka nebo servisní požadavek vznikne v systému, který je za ni odpovědný. Ten zveřejní obchodní událost v obálce CloudEvents, popsanou kontraktem AsyncAPI. Papírové objednávky, objednávky v PDF a dodavatelské faktury nejdřív projdou zpracováním dokumentů.
02
Krok 2: Rozeslání přes API a událostiSystém
Integrační vrstva doručí událost do skladového, dopravního, účetního a CRM systému přes jejich zdokumentovaná API (OpenAPI). Příjemci jsou idempotentní, takže opakovaná zpráva nikdy nevytvoří druhou zásilku ani fakturu, a zprávy, které nelze doručit, čekají ve frontě chyb na opětovné zpracování.
03
Krok 3: Časová osa objednávkySystém
Stavové události ze všech systémů (potvrzeno, vychystáno, odesláno, doručeno, fakturováno, zaplaceno) se podle obchodní reference spojí do jedné časové osy. Pravidla pro milníky a tolerance vyvolají výjimku, když krok selže, zpozdí se nebo nesouhlasí: nedostatek zásob, cena mimo dohodnutou toleranci, nedoručená zásilka, odmítnutá e-faktura.
04
Krok 4: Kontext a návrh řešeníAI agent
Agent ke každé výjimce načte z dotčených systémů, co potřebuje: objednávku, stav zásob, cenovou dohodu, stav u dopravce a podmínky zákazníka. Navrhne řešení i se zdůvodněním a použitými daty, například náhradní položku, opravenou cenu, nový termín dodání nebo opravnou fakturu.
Postup při výjimce: Krok selhal nebo je mimo toleranci
05
Krok 5: Schválení v rámci limitůČlověk
Pracovník zákaznického servisu, logistiky nebo účtárny vidí na pracovišti pro výjimky výjimku, podklady a návrh a schválí ho, upraví nebo odmítne. Schválený krok se provede přes API odpovědného systému, který změnu zveřejní jako novou událost.
Postup při výjimce: Krok selhal nebo je mimo toleranci· Vrací se ke kroku 2
Kontrola člověkem
Agenti nikdy bez schválení neúčtují finanční transakce, nemění ceny ani úvěrové limity a nic zákazníkovi nepřislibují. Limity pro každý typ kroku určují, kdo schvaluje, a každý návrh i rozhodnutí se zaznamená.
06
Krok 6: Fakturace, párování a úhradaSystém
Vydané faktury odcházejí z ERP jako strukturované e-faktury ve formátu ISDOC nebo Peppol BIS Billing 3.0 podle normy EN 16931, podle toho, co odběratel přijímá. Přijaté dodavatelské faktury se párují s objednávkami a příjemkami a stav platby od banky nebo poskytovatele plateb uzavře časovou osu.
07
Krok 7: Revize toku a příčinČlověk
Vlastníci procesů a integrační tým v pravidelném rytmu procházejí výjimky podle důvodu, chyby rozhraní a rozpory v kmenových datech. Opravují příčinu tam, kde vzniká, v záznamu kmenových dat, pravidle tolerance nebo mapování, místo aby stejnou výjimku řešili znovu.
Komponenty
Co bychom postavili
01
Integrační vrstva řízená událostmi
API a události mezi ERP, CRM, e-shopem, skladem, dopravou a účetnictvím, navržené nejdřív jako kontrakt v OpenAPI a AsyncAPI s obálkami CloudEvents, na vaší stávající integrační platformě nebo postavené cloud native.
Dohodnutý odpovědný systém a vlastník pro každý datový objekt, pravidla párování odběratelů, dodavatelů a produktů a přehledy duplicit a rozporů pro lidi, kteří za ně odpovídají.
Služba, která spojuje události do jedné časové osy pro každou objednávku nebo požadavek, uplatňuje pravidla pro milníky a tolerance a ukazuje vlastníkům procesů tok a výjimky.
Fronta výjimek se shromážděným kontextem a návrhem agenta, s možností schválit, upravit nebo odmítnout a s limity pro schválení vynucovanými u každého typu kroku v místě, kde se krok provádí.
Faktury ve formátu ISDOC nebo Peppol BIS Billing 3.0 podle normy EN 16931 (UBL), odesílané a přijímané kanálem, který odběratel používá, zkontrolované před odesláním, s odmítnutými fakturami přesměrovanými na pracoviště pro výjimky.
Monitoring a upozornění pro každé rozhraní, provozní příručky pro provozní tým a řízené opětovné zpracování neúspěšných zpráv, nasazené jako infrastruktura v kódu ve vašem cloudovém prostředí.
Salesforce Sales, Service a Commerce CloudPlatformaSalesforce
Prodej, sklad, nákup a účetnictví v OdooPlatformaOdoo
E-commerce platformy, tržiště a API dopravců
Systémy pro řízení skladu a dopravy
Přístupový bod Peppol, banky a poskytovatelé plateb
Správa produktových informací a datová platforma
Kontrolní mechanismy
Zabudované kontrolní mechanismy
Hranice přístupu
Každá integrace i agent běží v každém systému pod vlastní servisní identitou, omezenou na operace API, které potřebují. Agent smí kvůli kontextu číst napříč systémy, ale zapisovat může jen přes krátký seznam schválených kroků, které provádí API odpovědného systému, nikdy přímým přístupem do databáze.
Kontrola člověkem
Limity pro schválení se nastavují s vlastníkem procesu pro každý typ kroku: co smí agent jen navrhnout, co schvaluje člen týmu a co potřebuje druhého schvalovatele. Finanční zaúčtování, změny cen a úvěrových limitů a závazky vůči zákazníkům vždy čekají na člověka. Kroky s malým dopadem, které lze vrátit, například opětovné odeslání neúspěšné zprávy, mohou proběhnout bez schválení, pokud s tím vlastník souhlasí.
Auditovatelnost
Každá událost, návrh, schválení, odmítnutí i provedený krok se zaznamená k referenci objednávky nebo požadavku, s daty, která agent použil, verzí modelu a promptu a se schvalovatelem. Spornou fakturu nebo reklamaci zákazníka lze dohledat krok za krokem.
Ochrana dat
Kontaktní údaje odběratelů a dodavatelů proudí jen do systémů, které je potřebují. Časová osa ukládá obchodní reference a stavy, ne celé záznamy, a záznamy se uchovávají po dobu, kterou stanovíte. Zpracování probíhá v dohodnutém regionu.
Transparentnost AI
Návrhy agenta jsou na pracovišti pro výjimky takto označené a vedle nich jsou vidět podklady a zdůvodnění. Odpovědné systémy zůstávají rozhodující: časová osa ukazuje, co hlásí, a nikdy je nepřepisuje.
Ukazatele
Co bychom měřili
Tyto ukazatele s vámi dohodneme během úvodní analýzy a výchozí stav převezmeme ze záznamů vašich současných systémů a rozhraní dřív, než se cokoli změní.
Co bychom měřili
Ukazatel
Proč na něm záleží
Jak bychom ho měřili
01Doba cyklu objednávky
Proč na něm záležíUkazatel, kterého si zákazníci všimnou nejdřív, a ten, který ukáže, kde objednávky čekají.
Jak bychom ho měřiliDoba od přijetí objednávky po doručení a po úhradu, podle kanálu a společnosti, z událostí na časové ose.
02Objednávky bez ručního zásahu
Proč na něm záležíUkazuje, jak velká část toku běží na čistých datech a dohodnutých pravidlech.
Jak bychom ho měřiliPodíl objednávek a požadavků, které dojdou k úhradě bez ručního kroku nebo výjimky, z časové osy.
03Výjimky podle důvodu a doba vyřešení
Proč na něm záležíUkáže, které příčiny odstranit nejdřív a zda pracoviště pro výjimky stíhá.
Jak bychom ho měřiliPočet výjimek podle kódu důvodu a doba od zjištění po provedené řešení, ze záznamů pracoviště pro výjimky.
04Podíl odmítnutých e-faktur
Proč na něm záležíOdmítnuté faktury zdržují platbu a obvykle ukazují na chyby v kmenových datech nebo mapování.
Jak bychom ho měřiliPodíl odmítnutých odeslaných a přijatých e-faktur podle důvodu, z odpovědí přístupového bodu a odběratelů.
05Chyby rozhraní a doba obnovy
Proč na něm záležíUkazuje, zda je integrační vrstva spolehlivá a zda se chyby rychle zjistí a opraví.
Jak bychom ho měřiliNeúspěšné zprávy na rozhraní a doba od chyby po úspěšné opětovné zpracování, z integračního monitoringu.
06Duplicity a rozpory v kmenových datech
Proč na něm záležíVětšina výjimek má původ v datech, která se mezi systémy liší.
Jak bychom ho měřiliOtevřené duplicity a rozporné hodnoty podle datového objektu a systému, z přehledů párování.
Dokud neznáme výchozí stav, cíle nestanovujeme.
Zavedení
Jak bychom řešení zavedli
Fáze 01
Úvodní analýza a mapa procesu
Jeden proces, například od objednávky po úhradu pro jeden prodejní kanál, a jeden typ výjimky. Zmapujeme systémy, rozhraní, vlastníky dat a to, jak se výjimky řeší dnes.
Kritéria dokončení
Proces, systémy a vlastníci dat zmapováni
První typ výjimky a limity pro schválení dohodnuty
Výchozí stav převzat ze současných záznamů
Fáze 02
Integrace a časová osa
Zdokumentovaná API a události pro dotčené systémy a časová osa běžící vedle stávajících rozhraní, aniž by je měnila.
Kritéria dokončení
Kontrakty událostí zveřejněny a verzovány
Časová osa odpovídá odpovědným systémům ve vzorku objednávek
Opětovné zpracování a provozní příručky otestovány
Fáze 03
Pilot pracoviště pro výjimky
Agent navrhuje řešení pro vybraný typ výjimky a lidé schvalují každý návrh. Návrhy porovnáváme s tím, co by udělali pracovníci.
Kritéria dokončení
Kvalita návrhů splňuje dohodnutá kritéria
Limity a schvalovatelé nastaveni pro každý typ kroku
Auditní stopu zkontrolovaly účtárna a interní kontrola
Fáze 04
Rozšíření a vyřazení
Další typy výjimek, kanály, společnosti a procesy, například od nákupu po platbu, vždy na stejných kontraktech. Stará propojení bod s bodem se vypínají jedno po druhém.
Kritéria dokončení
Každý nový tok na stejných kontraktech a monitoringu
Zakázková výroba a objednávky náhradních dílů od ERP po sklad a dopravce, s potvrzeními dodavatelů a e-fakturami spárovanými s objednávkami, a propojení MES s ERP u dodavatelů pro automobilový průmysl.
Pracovní příkazy údržby, objednávky u zhotovitelů a jejich faktury, sledované od požadavku po úhradu u krajských organizací pro správu a údržbu silnic.
Od nákupu po platbu se strukturovanými e-fakturami pro veřejné zadavatele i od nich, spárovanými s objednávkami a příjemkami před úhradou.
Ilustrativní příklad
Distributor s prodejem v Česku, Německu a na Slovensku
Situace
Distributor technického zboží prodává přes e-shop, dvě tržiště a obchodní zástupce v Česku, Německu a na Slovensku ze dvou skladů. Objednávky se znovu zadávají do ERP, dopravci hlásí problémy s doručením e-mailem a každý trh fakturuje jinak.
Systém
Objednávky, zásoby, zásilky a faktury proudí jako události mezi e-shopem, ERP, skladovým systémem a dopravci a každá objednávka má jednu časovou osu. Faktury odcházejí jako strukturované e-faktury ve formátu a kanálem, které daný odběratel přijímá, včetně ISDOC a Peppol.
Kde rozhoduje člověk
Nedostatek zásob a nedoručené zásilky končí na jednom pracovišti pro výjimky, kde agent navrhne náhradní položku nebo nový termín dodání. Zákaznický servis schvaluje každý návrh; změny cen a dobropisy potřebují schválení účtárny.
Co bychom měřili
Podíl objednávek bez ručního zásahu podle země a kanálu, výjimky podle důvodu a doba jejich vyřešení a podíl odmítnutých e-faktur podle země.
Česko
Jeden proces, několik zemí a formátů
Firmy, které z Česka prodávají i do Německa a na Slovensko, často provozují stejné procesy od objednávky po úhradu a od nákupu po platbu na různých instancích ERP, s různými dopravci a bankami. Doma se fakturuje v PDF nebo ve formátu ISDOC; veřejní zadavatelé musejí přijímat faktury podle normy EN 16931, dodavatelé je ale zasílat nemusejí. Balíček EU o DPH v digitální éře zavádí strukturovanou e-fakturaci jako standard pro přeshraniční plnění B2B uvnitř EU od 1. července 2030. Navrhujeme jednu integrační vrstvu, ve které jsou formát a kanál každého odběratele i každé země schované za stejné události, takže nový požadavek znamená nový konektor, ne nový proces.
Nařízení o datech, použitelné od 12. září 2025, stanoví pravidla pro změnu poskytovatele služeb zpracování dat, proto držíme kontrakty událostí a exporty dat přenositelné. Agenty na pracovišti pro výjimky navrhujeme s ohledem na akt o umělé inteligenci a integrace dodáváme se zaznamenaným přístupem a zdokumentovanými komponentami pro odběratele, kteří musejí podle zákona o kybernetické bezpečnosti (zákon č. 264/2025 Sb.) doložit bezpečnost dodavatelského řetězce.
Ne. Vaše ERP, CRM, e-shop a skladový systém dělají každý svou práci. Integrujeme kolem těchto odpovědných systémů, dohodneme, který systém vlastní která data, a procesu dáme jednu časovou osu napříč nimi. Kde změnu blokuje starý objednávkový systém nebo ERP, nejdřív ho modernizace starších systémů schová za API.
02Nahradíte náš integrační middleware?
Ne, pokud plní svou úlohu. Stavíme na integrační platformě nebo message brokeru, který už provozujete, a doplníme kontrakty, monitoring a opětovné zpracování, kde chybějí. Kde žádný není, stavíme cloud native. Víc o naší službě Integrace a API.
03Mohou agenti jednat sami?
Jen v rámci limitů, které dohodnete pro každý typ kroku, a jen u kroků s malým dopadem, které lze vrátit, například opětovného odeslání neúspěšné zprávy. Finanční zaúčtování, ceny, úvěrové limity a závazky vůči zákazníkům vždy potřebují člověka. Přečtěte si, kde AI agenti potřebují schválení člověkem.
04Jak do toho zapadá povinná e-fakturace?
V Česku musejí veřejní zadavatelé přijímat elektronické faktury podle normy EN 16931 (§ 221 zákona č. 134/2016 Sb.), dodavatelé je ale zasílat nemusejí a povinná e-fakturace mezi firmami pro rok 2026 zavedena ani ohlášena není. Balíček EU o DPH v digitální éře (ViDA) zavádí strukturovanou e-fakturaci jako standard pro přeshraniční plnění B2B uvnitř EU od 1. července 2030. E-fakturu proto bereme jako další událost v procesu: vystaví ji ERP, odejde ve formátu ISDOC nebo přes síť Peppol, a když ji odběratel odmítne, řeší se na pracovišti pro výjimky. Podívejte se na našeho průvodce e-fakturou ISDOC a Peppol.
05Jak se vyhnout další křehké síti propojení bod s bodem?
Systémy zveřejňují a odebírají zdokumentované události a API přes jednu vrstvu, ne přímými propojeními mezi sebou. Kontrakty jsou verzované, příjemci idempotentní, neúspěšné zprávy lze zpracovat znovu a každý tok má jmenovitého vlastníka. Nový kanál se přihlásí k odběru existujících událostí, místo aby přidal propojení ke každému systému.
06Jak může vypadat první etapa?
Jeden proces a jeden typ výjimky, například od objednávky po úhradu pro jeden prodejní kanál s nedostatkem zásob jako první výjimkou. To ověří události, časovou osu i schvalování dřív, než se přidá další. Přečtěte si o našem přístupu k realizaci.
Proberme vaše toky objednávek a faktur
Vyberte jeden proces a země, ve kterých běží. Společně zmapujeme systémy, rozhraní a výjimky a navrhneme první vydání, které bude fungovat napříč vašimi společnostmi.