Napojení systému na účetnictví, banky a datové schránky

01Rozdělte propojení na konkrétní úkony

„Napojit banku a účetnictví“ není dostatečné zadání. Může to znamenat stahování pohybů, párování úhrad, vytvoření návrhu platby nebo její skutečné odeslání. U datové schránky je zase rozdíl mezi přehledem zpráv, stažením příloh, předáním odpovědnému člověku a odesláním podání. Každý úkon má jiný dopad a potřebuje vlastní pravidla.

Začněte seznamem situací, které dnes způsobují přepisování, čekání nebo nejistotu. U každé určete zdroj údajů, cílový systém, požadovanou rychlost a člověka pro výjimky. U malého objemu může stačit podporovaný import souboru a přehledná kontrola. Vývoj na míru se vyplatí posuzovat tam, kde opakovaná ruční práce nebo složitá oprávnění hotovému postupu skutečně překážejí.

Při volbě mezi importem, hotovým konektorem a vlastním řešením pomůže průvodce propojením systémů přes API.

02Účetnictví potřebuje přesné mapování a odpověď

U účetního programu ověřte verzi, licenci, podporované agendy a provozní podmínky rozhraní. Například XML import POHODA pracuje s definovanými schématy a vrací podrobnosti o zpracování jednotlivých dokladů. Z pouhého úspěšného přenosu souboru proto nevyvozujte, že byl přijat každý záznam.

Rozsah navrhujte po agendách. Výrobce zveřejňuje seznam podporovaných dat, včetně banky a fakturace. Je to příklad konkrétního produktu, nikoli důkaz, že všechny účetní programy umějí stejné operace. U vašeho systému nechte dodavatele doložit právě požadovanou kombinaci čtení, založení a opravy.

Spolu s účetní připravte mapování identifikátorů, měn, číselných řad, středisek a stavů. Určete, který systém smí údaj změnit. Pokud účetní uzavře období, integrační proces nesmí bez domluveného pravidla přepsat historický doklad. Zkoušejte také částečně odmítnutou dávku: přijaté položky zůstávají evidované a odmítnuté dostanou opravitelný důvod, nikoli jen obecné hlášení.

Konkrétní průchod dokladu ukazuje článek od objednávky z e-shopu do účetnictví bez přepisování.

03Čtení účtu a odeslání platby jsou různá oprávnění

Rozlišujte vlastní bankovní rozhraní, smluvní firemní kanál a službu otevřeného bankovnictví. Například česká dokumentace Fio API popisuje import hromadných plateb připravených k podpisu v internetovém bankovnictví. Vedle toho uvádí samostatné rozhraní otevřeného bankovnictví pro licencované subjekty. Tato rozhraní nezaměňujte.

Evropský rámec PSD2 rozlišuje informování o účtu a iniciování plateb, pracuje se souhlasem uživatele a pravidly silného ověření včetně výjimek. Neznamená volný přístup k libovolnému účtu pomocí univerzálního klíče. Pro konkrétní službu ověřte přístupový model, oprávnění poskytovatele a schvalování přímo s bankou.

Pokud potřebujete pouze párovat příchozí úhrady, nezačínejte oprávněním odesílat peníze. U plateb určete, kdo vytvoří návrh, kdo zkontroluje příjemce a kdo schválí dávku. Do návrhu zahrňte odmítnutí platby, změnu oprávněné osoby a vypršení nebo odvolání přístupu. Obnovení připojení musí mít vlastníka i zastupitelnost.

04Datová schránka potřebuje samostatný provozní postup

Český ISDS má oficiální testovací prostředí určené také k ověření externích aplikací přes webové služby. Postup získání testovacího přístupu uvádí aktuální nápověda pro vývojáře. Integraci proto zkoušejte mimo ostrou úřední komunikaci a podle dokumentace konkrétní operace.

V interním procesu oddělte technické stažení zprávy, přidělení odpovědné osobě a skutečné vyřízení. Zachovejte identifikátory, přílohy a dostupné doklady o stavech komunikace. Neodvozujte právní účinky doručení z toho, zda někdo klikl na tlačítko ve vašem systému. U konkrétních operací si nechte ověřit jejich účinky a návazné lhůty pro daný typ zprávy.

Archivaci navrhněte samostatně: co uchováváte, kdo se k tomu dostane, jak dlouho a jak ověříte obnovu. Nespoléhejte na neurčité tvrzení, že zprávy zůstanou ve schránce navždy. Pokud firma působí i na Slovensku, jde o jiný systém. Slovenské podmínky ÚPVS v článku 30 popisují vlastní integrační proces a technický účet. Český konektor nelze považovat za hotové slovenské řešení.

05Navrhněte opakování bez dvojího provedení

Pro každý přenos uložte jeho identifikátor, zdroj, cíl a poslední ověřený výsledek. Po výpadku chcete vědět, co se dá bezpečně zopakovat. Idempotence znamená, že opakování stejného požadavku nezpůsobí další nechtěný účinek. Je to vlastnost, kterou musíte u konkrétní operace navrhnout a otestovat, ne automatická výhoda každého API.

Modelový případ: systém odešle návrh dokladu a spojení skončí dřív, než dorazí odpověď. Nejprve se pokusí dohledat výsledek podle společného identifikátoru. Teprve podle něj rozhodne o opakování. U plateb a podání je obzvlášť důležité neztotožnit neznámý výsledek s neúspěchem. Když stav nejde ověřit automaticky, vznikne úkol pro člověka.

V návrhu integrace systémů přes API požadujte i nástroj na dohledání a opravu chyb. Účetní má rozumět tomu, který doklad čeká a proč. Neměla by kvůli běžné opravě hledat vývojáře, který jako jediný přečte technický záznam.

06Chraňte přístupy a rozdělte odpovědnosti

Veďte seznam přístupů, jejich rozsahu, vlastníka a způsobu zneplatnění. Tajné klíče a certifikáty nepatří do tabulky přiložené k zadání ani do zdrojového kódu. Oddělte testovací a ostré prostředí. Pro čtení, změny dokladů, schvalování plateb a úřední podání používejte oprávnění odpovídající konkrétní práci.

Provozní záznam má umožnit dohledat, kdo co spustil a jaký výsledek systém ověřil. Nemusí kvůli tomu obsahovat všechny přílohy, celé výpisy nebo přístupové tokeny. Dohodněte, kdo řeší obsahovou chybu, kdo obnoví spojení a kdo rozhodne při nejasném stavu. Bez toho pouze přesunete ruční práci do méně srozumitelné technické fronty.

Součástí dohody má být i odpovědnost dodavatele za změny okolních služeb. Určete, kdo sleduje oznámené změny bankovního přihlášení nebo aktualizace účetního programu a kdo ověří kompatibilitu. U podpory napište, jaké podklady firma předá při závadě a co už je placená změna rozsahu. Zároveň oddělte opravu konektoru od rozhodnutí o věcné správnosti dokladu. Dodavatel může obnovit přenos, ale odpovědnost za účetní obsah potřebuje konkrétního odborného vlastníka ve firmě nebo u externí účetní.

07Spouštějte po etapách a sledujte stáří chyb

Vyberte malý, kontrolovatelný rozsah a stanovte přejímací situace před implementací. Nejdřív můžete ověřit čtení a porovnávání dat, potom řízený zápis. Každá etapa má mít návratový postup a odpovědného člověka. Pro dlouhodobý servis a správu evidujte změny rozhraní, obnovu přístupů a kontrolu záloh.

1. Ověřte běžný případ i položku, kterou cílový systém odmítne.
2. Opakujte stejný požadavek a zkontrolujte vznik případné duplicity.
3. Přerušte spojení po odeslání a před přijetím odpovědi.
4. Odvolejte testovací přístup a ověřte upozornění odpovědné osobě.
5. Obnovte uložený dokument a jeho související provozní záznam.
6. Nechte zastupujícího kolegu vyřešit výjimku podle návodu.

Sledujte poslední úspěšnou synchronizaci, nejstarší nevyřízenou chybu a počet případů čekajících na člověka. Zelený stav běžícího serveru nestačí. Integrace může technicky fungovat a přitom několik dní nepřenést žádný nový doklad.

08Časté otázky

09Připravte zadání integrace

Pošlete nám seznam systémů, bank a schránek i tři ruční úkony. Navrhneme první etapu s jasným výsledkem, potřebnými oprávněními a kontrolou výjimek.