Objednávka vznikne v e-shopu, obchodník pracuje v CRM, sklad hlídá pohyb zboží a účetní systém potřebuje znát fakturu i její úhradu. Když si jednotlivé systémy údaje předávají ručním exportem, vzniká prodleva a prostor pro chybu. API dává systémům společný, kontrolovatelný způsob, jak si data předat bez opisování.
U napojení na MyÚčto není cílem přenést všechno, co kde existuje. Cílem je zvolit informace, které mají jasného vlastníka. E-shop typicky vytvoří objednávku a může předat podklady pro vydanou fakturu. MyÚčto vrátí číslo dokladu, stav vystavení, odeslání nebo úhrady. Každý systém tak zůstává dobrý v tom, pro co je určený.
Nejdřív určete, kde vzniká pravda
Před prvním voláním API je užitečné popsat jednoduchý tok. Kde se zakládá odběratel? Kdy se může vystavit faktura? Kdo smí upravit částku? Odkud se dozví e-shop, že byla platba spárována? Bez těchto odpovědí se integrace snadno promění v oboustranné přepisování, ve kterém nikdo neví, která hodnota platí.
Dobré napojení proto přenáší konkrétní události. Nová objednávka vytvoří návrh dokladu. Změna kontaktu aktualizuje odběratele. Vystavení faktury vrátí její identifikátor. Úhrada informuje obchodní nebo zákaznický systém, že může navázat další proces. Každý krok má jasný účel a je možné jej dohledat.
API má být čitelné i pro člověka
Integrace občas selže: vypadne spojení, dorazí neúplný údaj nebo externí systém pošle stejnou událost dvakrát. To není výjimka, kterou lze ignorovat. MyÚčto proto potřebuje vést záznam volání, stav odpovědi a vazbu na konkrétní doklad. Vývojář vidí, co opravit. Účetní vidí, proč se faktura neobjevila tam, kde ji čekal.
Stejně důležitá jsou oprávnění. Token pro čtení přehledů nemá automaticky právo odesílat faktury nebo vytvářet účetní zápisy. Rozsah přístupu nastavte podle úlohy systému a pravidelně kontrolujte, které tokeny jsou aktivní. Integrace pak není tajná zkratka do celé firmy, ale omezený nástroj pro konkrétní proces.
Příklady, které šetří ruční práci
E-shop může po zaplacení objednávky předat údaje k vystavení dokladu. CRM může založit odběratele spolu s odsouhlasenou zakázkou. Interní docházkový systém může předat schválený výkaz práce pro fakturaci. Na opačnou stranu se může vracet číslo faktury, PDF podklad, stav odeslání nebo informace, že závazek byl uhrazen.
Vždy ale zvažte, zda je automatické předání opravdu správný krok. Objednávka s nestandardní cenou může nejdřív čekat na schválení. Doklad s chybějícím DIČ nemusí API odmítnout bez vysvětlení; může vrátit konkrétní chybu, kterou pracovník v původním systému opraví. Cílem není data protlačit za každou cenu, ale udržet je správná.
Začněte jedním uzavřeným tokem
Rozumný první projekt je takový, který má jasný začátek a konec. Třeba převod schválené objednávky na koncept faktury. Ověřte, že se doklad nevytvoří dvakrát, že lze najít jeho původ a že se chyba vrátí srozumitelně. Až potom přidávejte další směry, například stav úhrady nebo synchronizaci kontaktů.
Účetní u toho nemusí být programátor. Je ale správným člověkem pro popis pravidel, která integrace nesmí obejít. Díky tomu se API nestane jen technickým projektem, ale součástí funkčního účetního procesu.