Kde je „pravda“ o datech
První otázka nezní „jaké API“, ale „který systém má poslední slovo“. U každého údaje by mělo být jasné, kde vzniká a kde se jen zobrazuje. Když cenu produktu upravujete v e-shopu i ve skladovém programu, napojení neví, která změna platí, a dřív nebo později jednu přepíše.
Nejjednodušší je sepsat si krátkou tabulku. Nemusí být technická, stačí, aby se na ní shodl majitel, účetní a člověk, který vyřizuje objednávky.
| Údaj | Kde často vzniká | Na co se zeptat |
|---|---|---|
| Objednávka | E-shop | Posílá se do fakturace hned, nebo až po zaplacení? |
| Cena a DPH | E-shop nebo skladový program | Kde se cena mění a kdo ji smí měnit? |
| Stav skladu | Sklad | Jak často se má propsat do e-shopu? |
| Faktura a dobropis | Fakturace nebo účetnictví | Kdo doklad vystavuje a kdo ho smí opravit? |
| Zákazník | E-shop | Co se stane, když zákazník změní fakturační údaje? |
Pokud se na některém řádku neshodnete, je to dobrá zpráva: přišli jste na to před vývojem, ne po spuštění.
Číselné řady, DPH a zaokrouhlení
Číselné řady. Rozhodněte, kdo přiděluje číslo dokladu. Když číslo vzniká v e-shopu i ve fakturaci, snadno vzniknou dvě řady, díry nebo duplicity. Jaké požadavky na číslování máte, vám řekne vaše účetní; napojení je pak má jen dodržet.
DPH. Sepište, jaké sazby prodáváte, jestli máte zboží s různou sazbou v jedné objednávce a jak se účtuje doprava a platba. Pokud prodáváte do zahraničí nebo firmám s DIČ, patří to do zadání hned na začátku, ne jako výjimka po spuštění.
Zaokrouhlení. E-shop může počítat DPH po řádcích a fakturace za celý doklad. Rozdíl bývá v haléřích, ale stačí, aby se částka na faktuře lišila od zaplacené, a párování plateb přestane sedět. Vyberte si pár skutečných objednávek se slevou, dopravou a různými sazbami a nechte je spočítat v obou systémech. Kde se čísla rozejdou, tam je potřeba pravidlo.
Dobropisy, vratky a párování plateb
Hladká objednávka se napojuje snadno. Čas zabírají ty ostatní: částečná vratka, výměna za jinou velikost, storno po odeslání faktury, sleva přidaná dodatečně. U každé si odpovězte, kdo ji zadává, ve kterém systému a co se má propsat zpátky, například vrácení kusů na sklad.
- Vzniká dobropis automaticky při vratce, nebo ho vystavuje účetní ručně?
- Vrací se zboží na sklad hned, nebo až po kontrole?
- Jak poznáte, že platba patří ke konkrétní objednávce? Variabilní symbol, číslo objednávky, nebo něco jiného?
- Co s přeplatkem, nedoplatkem a platbou bez symbolu?
- Kdo řeší platbu, která dorazí po stornu objednávky?
U Layered jsme párování plateb nechali tam, kde už fungovalo. Po objednávce vznikne ve Fakturoidu proforma s QR platbou, příchozí platbu spáruje Fakturoid a webhookem dá vědět webu. Teprve potom vznikne konečný doklad a odejde vstupenka, přičemž systém hlídá, aby se nevystavila dvakrát. Web tedy nepáruje platby sám, jen reaguje na to, co fakturace potvrdí.
Integrace nerozhodne za vás, co je správně. Jen rychleji a přesněji udělá to, na čem jste se dohodli.
Přístupy k API a testovací prostředí
Než se něco slíbí, je potřeba zjistit, co druhá strana dovolí. Účetní a skladové programy se v tom liší: některé mají veřejné API, jiné jen export souborů nebo napojení přes doplněk, u některých je přístup k API součástí vyššího tarifu. To ověřujeme na začátku, ne uprostřed vývoje.
- Kdo účty vlastní. Přístupy a klíče by měly běžet na účtech firmy, ne na osobním účtu bývalého kolegy nebo dodavatele.
- Kdo dá přístup. Často je to účetní nebo externí správce. Počítejte s tím, že to může trvat pár dní.
- Oprávnění. Napojení potřebuje jen to, co opravdu dělá. Když má jen vystavovat faktury, nemusí mít přístup ke všemu.
- Testovací prostředí. Zjistěte, jestli váš program nabízí testovací účet nebo sandbox. Když ne, domluvte se, na čem se bude zkoušet, aby testovací faktury neskončily v ostré řadě.
- Testovací data. Připravte deset až dvacet skutečných objednávek, včetně těch nepříjemných: se slevou, vratkou, zahraničním zákazníkem.
Kdo bude napojení a kód vlastnit, patří do smlouvy. Přístupy, dokumentaci a rozsah předání zdrojového kódu si vyjasníme v nabídce a smlouvě před začátkem práce.
Co se stane při výpadku a kdo hlídá chyby
Každý systém občas nejede. Fakturace má údržbu, sklad neodpoví, zákazník vyplní IČO s překlepem. Otázka není, jestli se to stane, ale co pak. Objednávka by se neměla ztratit ani se odeslat dvakrát.
U napojení proto domlouváme tři věci. Co se zkouší znovu samo a kolikrát. Kam se zapíše, co neprošlo, aby bylo vidět co a proč, ne jen že se něco nepovedlo. A komu přijde upozornění. Opakování, logování a upozornění nastavujeme podle možností napojených systémů, ne každý program všechno dovolí.
Nejčastěji se zapomíná na poslední bod: jméno člověka. Upozornění, které chodí do sdílené schránky, kterou nikdo nečte, je stejné jako žádné. Určete, kdo chyby na vaší straně řeší, kdo je zástup v době dovolené a co je chyba provozní (špatné IČO) a co technická (napojení nejede). První týdny po spuštění bývají potřeba spíš úpravy pravidel než kódu.
Checklist na jednu stránku
- U každého údaje víme, který systém má poslední slovo.
- Víme, kdo přiděluje čísla dokladů, a účetní to odsouhlasila.
- Máme sepsané sazby DPH, dopravu, slevy a prodej do zahraničí.
- Pár skutečných objednávek jsme spočítali v obou systémech a částky sedí.
- Víme, jak se řeší vratka, storno, dobropis a platba bez symbolu.
- Přístupy k API jsou na účtu firmy a víme, kdo je vydá.
- Máme testovací účet nebo dohodu, kde se bude zkoušet.
- Máme sadu testovacích objednávek včetně výjimek.
- Víme, co se stane při výpadku, a kdo dostane upozornění.
Nemusíte mít všechno zodpovězené, abyste mohli začít. Stačí vědět, kde máte mezery, a projít je spolu na začátku. Jak napojení stavíme a co stojí jednotlivé rozsahy, najdete u služby Integrace a automatizace. Jedno napojení mezi dvěma systémy tam začíná od 18 000 Kč bez DPH.
Orientační rozsah si můžete spočítat v kalkulačce. Když chcete checklist projít rovnou nad vaším e-shopem, probereme projekt na 30minutové konzultaci.
