Co vás čeká v tomto článku?
Objednávka přijde do e-shopu, zaměstnanec ji přepíše do skladu, vystaví fakturu a po platbě znovu upraví stav objednávky. Každý krok už přitom probíhá v nějakém systému. Potíž je v tom, že systémy spolu nemluví.
Řešením může být hotový konektor, vlastní napojení nebo samostatná vrstva, která řídí celý proces. Správná volba nezávisí jen na počtu aplikací. Rozhodují data, výjimky a následky případné chyby.
Jedna objednávka, čtyři systémy
Problém většinou není v tom, že firmě chybí software. Nástrojů má dost. Objednávky eviduje e-shop, zásoby skladový systém, faktury účetní program a platby banka nebo platební brána. Problém vzniká mezi nimi.
Typická objednávka může projít touto cestou:
- Zákazník odešle objednávku v e-shopu.
- Sklad rezervuje nebo odepíše dostupné zboží.
- Fakturační systém vystaví doklad.
- Platební brána nebo banka potvrdí úhradu.
- Stav platby a expedice se vrátí do e-shopu.
Pokud každý krok vyžaduje zásah zaměstnance, lidé kopírují čísla objednávek, jména, adresy, ceny a variabilní symboly. Kromě času vzniká druhý problém: nikdo si nemůže být jistý, zda se všechny čtyři systémy shodují.
U každého údaje proto musí být jasné, kde vzniká a který systém za něj odpovídá. Objednávku může řídit e-shop, skutečný stav zásob sklad, daňový doklad fakturační systém a stav úhrady platební služba. Jde o modelový příklad, ne univerzální pravidlo. V některých firmách ceny určuje účetní nebo ERP systém a e-shop je pouze zobrazuje.
Stejně důležitý je směr přenosu. Nestačí říct, že se propojí sklad s e-shopem. Potřebuji vědět, zda e-shop do skladu posílá objednávky, sklad do e-shopu dostupnost, nebo oba systémy mění stejná data. Pokud mohou dva systémy nezávisle přepsat stejný údaj, dříve nebo později se rozejdou.
O tom, co API znamená a jak obecně propojuje aplikace, píšu samostatně v článku Co je API a jak vám zjednoduší procesy. Tady je podstatné něco jiného: kdo řídí celý obchodní případ od objednávky po zaplacení.
Počet propojených systémů sám o sobě nerozhoduje. Rozsah integrace určují hlavně pravidla, výjimky a následky chyby.
Kdy stačí konektor a kdy vlastní řešení
Nejlevnější rozumná varianta bývá hotové propojení. Pokud podporuje vaše data, správný směr přenosu a běžné výjimky, nemá smysl programovat totéž znovu. Vlastní řešení přichází na řadu až ve chvíli, kdy standardní konektor nestačí provozu firmy.
Hotový konektor
Konektor se hodí pro standardní proces. Objednávka má běžná pole, produkty mají shodné kódy, faktura vzniká vždy ve stejném okamžiku a případná chyba neohrozí navazující provoz.
Před nasazením je potřeba ověřit:
- která pole konektor přenáší,
- jak často data synchronizuje,
- co udělá při chybě,
- zda podporuje storna, dobropisy a částečné platby,
- kdo propojení aktualizuje po změně API.
U e-shopů často propojuji hotové fakturační nebo účetní služby, například Fakturoid či Pohodu. Firma získá prověřený systém pro fakturaci a vlastní vývoj řeší jen to, co je specifické pro její objednávky. Podobný princip popisuji v článku Fakturoid API: jak automatizovat fakturaci.
Vlastní přímé propojení
Přímé napojení dává smysl, když se dva konkrétní systémy potřebují domluvit podle pravidel, která hotový konektor neumí. Může jít o vlastní identifikaci zákazníků, převod číselníků, odlišné okamžiky fakturace nebo pravidla pro konkrétní skupiny odběratelů.
I propojení dvou aplikací může být náročné, pokud zpracovává velký objem dat, musí reagovat okamžitě nebo chyba zastaví expedici. Naopak několik jednoduchých nástrojů může fungovat přes hotové konektory bez vlastní centrální aplikace.
Vlastní integrační vrstva
Integrační vrstva je malá vlastní aplikace mezi ostatními systémy. Nepřebírá jejich práci. Hlídá, v jakém stavu je celý proces, co už proběhlo, co selhalo a co potřebuje zásah člověka.
Dává smysl, když:
- na jednu objednávku navazuje více systémů,
- data se musí převádět podle vlastních pravidel,
- výpadek jednoho systému nesmí ztratit objednávku,
- potřebujete dohledat historii každého kroku,
- zaměstnanci potřebují přehled nevyřízených výjimek,
- přibývají další napojení a přímé vazby začínají být nepřehledné.
Vrstva se nevyplatí jen proto, že zní robustněji. Pokud pouze přeposílá stejná data z bodu A do bodu B, přidává další místo k provozu a údržbě bez skutečné hodnoty.
Širší firemní systém
Někdy firma nepotřebuje jen přesouvat data. Potřebuje také řídit schvalování, práci zaměstnanců, reklamace, ruční opravy nebo vlastní agendu, kterou žádný ze stávajících nástrojů nepokrývá. Pak může dávat smysl informační systém na míru.
Ani tady není vlastní systém automatická odpověď. Schvalování nebo chybovou frontu může někdy převzít stávající firemní nástroj. Rozhoduje konkrétní proces a celkové náklady na provoz, ne název technologie.
Začínám nejmenším řešením, které zvládne skutečný provoz. Někdy je to konektor, jindy jedno vlastní napojení. Integrační vrstvu navrhuji až tam, kde musí někdo spolehlivě hlídat celý obchodní případ a jeho výjimky.
Pokud nevíte, do které varianty vaše situace patří, můžeme během úvodní konzultace projít jeden skutečný proces a oddělit nutné propojení od zbytečného vývoje. Domluvte si konzultaci.
Dobrá integrace se pozná podle výjimek
Běžný průchod objednávky bývá jednoduchý. Skutečný rozsah projektu ukážou až situace, kdy se něco změní nebo pokazí.
Co se stane, když:
- zákazník po objednání změní počet kusů,
- část zboží není skladem,
- objednávka se odešle na dvakrát,
- faktura už vznikla, ale objednávka se stornuje,
- zákazník zaplatí jen část částky,
- platba přijde bez správného identifikátoru,
- stejná informace dorazí do systému dvakrát,
- účetní program nebo skladové API několik hodin nefunguje,
- zaměstnanec opraví údaj přímo v jednom systému?
Spolehlivé propojení nesmí takový případ schovat. Musí ho buď bezpečně vyřešit, nebo zastavit na místě, kde ho převezme konkrétní člověk.
Zkušenost z přípravy propojení Septimu a Money S3
Při přípravě automatizace fakturace mezi Septimem a Money S3 fungoval přístup do API. To ale ještě neznamenalo, že bylo možné začít přenášet faktury.
Ukázalo se, že dostupná data neobsahovala všechny údaje potřebné pro jednoznačné spárování odběratele a objednávky. Testovací prostředí navíc obsahovalo obecná ukázková data, ne skutečné varianty z provozu klienta. Před vývojem proto bylo nutné vyjasnit číselníky, pravidla pro různé skupiny odběratelů, povinné číslo objednávky a okamžik, kdy má faktura vzniknout.
Projekt zde uvádím jako zkušenost z návrhu a ověřování integrace, ne jako tvrzení o dokončeném výsledku nebo dosažené úspoře. Dobře ale ukazuje, proč nelze propojení poctivě nacenit jen podle názvů dvou systémů.
Chybová fronta místo tichého selhání
Pokud cílový systém krátce neodpovídá, může se přenos později bezpečně zopakovat. Pokud ale objednávce chybí zákazník, produkt nemá odpovídající skladovou kartu nebo stav nedává smysl, další pokusy nic neopraví.
Takový případ má skončit v přehledu pro ruční kontrolu. Uživatel musí vidět:
- které objednávky se problém týká,
- ve kterém kroku se zastavila,
- proč ji systém odmítl,
- jaká data přišla ze zdroje,
- co je potřeba opravit,
- zda lze proces po opravě znovu spustit.
Obnova po výpadku závisí na možnostech konkrétního API. Někde lze bezpečně zopakovat původní událost. Jinde je správnější načíst aktuální stav objednávky a porovnat ho s ostatními systémy. Důležité je, aby opakování nevytvořilo druhou fakturu nebo znovu neodepsalo sklad.
Při popisu integrace nezačínejte seznamem funkcí. Vezměte jednu skutečnou objednávku, projděte její cestu firmou a přidejte dvě nebo tři výjimky, které zaměstnanci řeší jinak než obvykle.
Kde může pomoct AI
Přesun objednávky z e-shopu do skladu není AI. Jde o běžné API, kontrolu dat a jasná pravidla.
AI může pomoct ve chvíli, kdy objednávka přijde volným e-mailem, jako PDF nebo v pokaždé trochu jiném dokumentu. Dokáže navrhnout, kdo objednává, jaké položky chce a kam je dodat. Než však vznikne skladový nebo finanční zápis, pevná pravidla ověří povinná pole, zákazníka, položky, jednotky a duplicity. Nejasný případ dostane člověk ke kontrole.
Takové rozdělení používám i u širší automatizace firemních procesů: běžný přenos dat drží předvídatelný kód, AI pomáhá tam, kde je vstup nejasný nebo nestrukturovaný.
Co potřebuji vědět, abych mohl propojení nacenit
Poptávka „propojte nám e-shop se skladem a účetnictvím“ nestačí pro pevný odhad. Nejdřív potřebuji vědět, co přesně se má stát s jednou běžnou objednávkou a s každou důležitou výjimkou.
Připravte si tyto podklady:
- Seznam systémů a jejich role. Kde vzniká objednávka, sklad, faktura a informace o platbě?
- API dokumentaci a přístupy. Existuje veřejné API, testovací účet a prostředí podobné skutečnému provozu?
- Seznam přenášených údajů. Nestačí objednávka. Potřebuji znát zákazníka, adresy, položky, ceny, měny, daně, slevy, dopravu, identifikátory a stavy.
- Směr a okamžik přenosu. Co se posílá kam a kdy má další krok začít?
- Objem a špičky. Kolik záznamů běžně vzniká a jak vypadá nejsilnější období?
- Mapování identifikátorů a číselníků. Jak se pozná stejný zákazník, produkt, pobočka nebo objednávka v různých systémech?
- Běžné výjimky. Storna, změny, částečné dodání, dobropisy, chybějící zboží nebo opožděné platby.
- Pravidla ruční kontroly. Co se smí opravit automaticky a co musí schválit člověk?
- Historická data. Má se propojit jen nový provoz, nebo také převést staré objednávky, faktury a skladové pohyby?
- Požadavky na dohled a podporu. Kdo dostane upozornění, jak rychle se musí chyba řešit a kdo odpovídá za změny cizího API?
Ne všechny podklady musí být hotové před prvním hovorem. Bez nich ale lze dát jen orientační rozsah. Přesnější nabídka vznikne až po kontrole dokumentace, vzorků dat a výjimek.
Co si z článku odnést?
- Hotový konektor stačí, pokud podporuje potřebná data, směr přenosu i běžné výjimky.
- Vlastní napojení řeší konkrétní pravidla, která standardní konektor neumí.
- Integrační vrstva má smysl, když musí hlídat stav celého procesu, historii a chyby napříč více systémy.
- AI patří ke čtení nejasných e-mailů a dokumentů. Běžný přenos dat má zůstat předvídatelný.
- Pro nacenění jsou důležitější reálná data a výjimky než pouhý seznam aplikací.
Časté otázky
Kolik stojí API integrace mezi firemními systémy?
Bez kontroly procesu, dokumentace a vzorků dat lze dát jen orientační rozsah. Cenu ovlivňuje počet směrů přenosu, převod číselníků, výjimky, požadovaná rychlost, chybová fronta, historie a následná podpora. Dva stejné názvy systémů proto neznamenají stejnou cenu projektu.
Jak dlouho propojení systémů trvá?
Záleží na připravenosti API, kvalitě testovacích dat a počtu výjimek. Jednoduché napojení dvou standardních služeb má jiný rozsah než proces objednávka, sklad, faktura a platba s několika větvemi. Reálný harmonogram lze určit až po technickém ověření.
Co se stane, když API jednoho systému vypadne?
Dobré propojení požadavek nezahodí. Podle situace přenos bezpečně zopakuje, načte aktuální stav nebo případ přesune do přehledu pro ruční kontrolu. Součástí návrhu musí být ochrana před duplicitní fakturou, opakovaným odpisem skladu a dalšími následky opakování.
Lze firemní systémy propojit bez AI?
Ano. Strukturovaná data mezi e-shopem, skladem, účetnictvím a platební službou se běžně přenášejí přes API a pevná pravidla. AI má přínos hlavně u e-mailů, PDF a dalších vstupů, které nemají stálou podobu.
Co když jeden ze systémů nemá API?
Nejdřív je potřeba ověřit jiné bezpečné možnosti, například pravidelný import a export nebo podporované datové rozhraní. Pokud systém neumí spolehlivě data přijímat ani vydávat, může být rozumnější změnit danou část procesu než stavět křehké obcházení.
Potřebujete propojit nástroje, které už ve firmě používáte? Napište mi. Projdeme konkrétní proces, dostupná API a místa, kde dnes vzniká ruční práce. Pak navrhnu nejmenší řešení, které zvládne i reálné výjimky.
Stavím firmám AI agenty a automatizace na míru
Pavel Szabo
Programátor webů, eshopů a informačních systémů s více než 23 lety praxe. Pomáhám firmám i jednotlivcům s online podnikáním, automatizacemi a využitím AI v praxi.
