Čo pripraviť pred napojením účtovníctva a e-shopu?

Kde je „pravda“ o dátach

Prvá otázka neznie „aké API“, ale „ktorý systém má posledné slovo“. Pri každom údaji by malo byť jasné, kde vzniká a kde sa len zobrazuje. Keď cenu produktu upravujete v e-shope aj v skladovom programe, napojenie nevie, ktorá zmena platí, a skôr či neskôr jednu prepíše.

Najjednoduchšie je spísať si krátku tabuľku. Nemusí byť technická, stačí, aby sa na nej zhodol majiteľ, účtovníčka a človek, ktorý vybavuje objednávky.

Ak sa na niektorom riadku nezhodnete, je to dobrá správa: prišli ste na to pred vývojom, nie po spustení.

Číselné rady, DPH a zaokrúhlenie

Číselné rady. Rozhodnite, kto prideľuje číslo dokladu. Keď číslo vzniká v e-shope aj vo fakturácii, ľahko vzniknú dve rady, diery alebo duplicity. Aké požiadavky na číslovanie máte, vám povie vaša účtovníčka; napojenie ich potom má len dodržať.

DPH. Spíšte, s akými sadzbami predávate, či máte tovar s rôznou sadzbou v jednej objednávke a ako sa účtuje doprava a platba. Ak predávate do zahraničia alebo firmám s IČ DPH, patrí to do zadania hneď na začiatku, nie ako výnimka po spustení.

Zaokrúhlenie. E-shop môže počítať DPH po riadkoch a fakturácia za celý doklad. Rozdiel býva v centoch či halieroch, ale stačí, aby sa suma na faktúre líšila od zaplatenej, a párovanie platieb prestane sedieť. Vyberte si pár skutočných objednávok so zľavou, dopravou a rôznymi sadzbami a nechajte ich spočítať v oboch systémoch. Kde sa čísla rozídu, tam treba pravidlo.

Dobropisy, vratky a párovanie platieb

Hladká objednávka sa napája ľahko. Čas zaberajú tie ostatné: čiastočná vratka, výmena za inú veľkosť, storno po odoslaní faktúry, zľava pridaná dodatočne. Pri každej si odpovedzte, kto ju zadáva, v ktorom systéme a čo sa má prepísať späť, napríklad vrátenie kusov na sklad.

• Vzniká dobropis automaticky pri vratke, alebo ho vystavuje účtovníčka ručne?
• Vracia sa tovar na sklad hneď, alebo až po kontrole?
• Ako spoznáte, že platba patrí ku konkrétnej objednávke? Variabilný symbol, číslo objednávky, alebo niečo iné?
• Čo s preplatkom, nedoplatkom a platbou bez symbolu?
• Kto rieši platbu, ktorá príde po storne objednávky?

Pri Layered sme párovanie platieb nechali tam, kde už fungovalo. Po objednávke vznikne vo Fakturoide proforma s QR platbou, prichádzajúcu platbu spáruje Fakturoid a webhookom dá vedieť webu. Až potom vznikne konečný doklad a odíde vstupenka, pričom systém stráži, aby sa nevystavila dvakrát. Web teda nepáruje platby sám, len reaguje na to, čo fakturácia potvrdí.

Integrácia nerozhodne za vás, čo je správne. Len rýchlejšie a presnejšie urobí to, na čom ste sa dohodli.

Prístupy k API a testovacie prostredie

Skôr než sa niečo sľúbi, treba zistiť, čo druhá strana dovolí. Účtovné a skladové programy sa v tom líšia: niektoré majú verejné API, iné len export súborov alebo napojenie cez doplnok, pri niektorých je prístup k API súčasťou vyššieho tarifu. To overujeme na začiatku, nie uprostred vývoja.

• Kto účty vlastní. Prístupy a kľúče by mali bežať na účtoch firmy, nie na osobnom účte bývalého kolegu alebo dodávateľa.
• Kto dá prístup. Často je to účtovníčka alebo externý správca. Počítajte s tým, že to môže trvať pár dní.
• Oprávnenia. Napojenie potrebuje len to, čo naozaj robí. Keď má len vystavovať faktúry, nemusí mať prístup ku všetkému.
• Testovacie prostredie. Zistite, či váš program ponúka testovací účet alebo sandbox. Ak nie, dohodnite sa, na čom sa bude skúšať, aby testovacie faktúry neskončili v ostrej rade.
• Testovacie dáta. Pripravte desať až dvadsať skutočných objednávok, vrátane tých nepríjemných: so zľavou, vratkou, zahraničným zákazníkom.

Kto bude napojenie a kód vlastniť, patrí do zmluvy. Prístupy, dokumentáciu a rozsah odovzdania zdrojového kódu si vyjasníme v ponuke a zmluve pred začiatkom práce.

Čo sa stane pri výpadku a kto stráži chyby

Každý systém občas nejde. Fakturácia má údržbu, sklad neodpovie, zákazník vyplní IČO s preklepom. Otázka nie je, či sa to stane, ale čo potom. Objednávka by sa nemala stratiť ani odoslať dvakrát.

Pri napojení preto dohadujeme tri veci. Čo sa skúša znova samo a koľkokrát. Kam sa zapíše, čo neprešlo, aby bolo vidieť čo a prečo, nie len že sa niečo nepodarilo. A komu príde upozornenie. Opakovanie, logovanie a upozornenia nastavujeme podľa možností napojených systémov, nie každý program všetko dovolí.

Najčastejšie sa zabúda na posledný bod: meno človeka. Upozornenie, ktoré chodí do zdieľanej schránky, ktorú nikto nečíta, je rovnaké ako žiadne. Určte, kto chyby na vašej strane rieši, kto je zástup počas dovolenky a čo je chyba prevádzková (zlé IČO) a čo technická (napojenie nejde). Prvé týždne po spustení bývajú potrebné skôr úpravy pravidiel než kódu.

Checklist na jednu stranu

• Pri každom údaji vieme, ktorý systém má posledné slovo.
• Vieme, kto prideľuje čísla dokladov, a účtovníčka to odsúhlasila.
• Máme spísané sadzby DPH, dopravu, zľavy a predaj do zahraničia.
• Pár skutočných objednávok sme spočítali v oboch systémoch a sumy sedia.
• Vieme, ako sa rieši vratka, storno, dobropis a platba bez symbolu.
• Prístupy k API sú na účte firmy a vieme, kto ich vydá.
• Máme testovací účet alebo dohodu, kde sa bude skúšať.
• Máme sadu testovacích objednávok vrátane výnimiek.
• Vieme, čo sa stane pri výpadku, a kto dostane upozornenie.

Nemusíte mať všetko zodpovedané, aby ste mohli začať. Stačí vedieť, kde máte medzery, a prejsť ich spolu na začiatku. Ako napojenia staviame a čo stoja jednotlivé rozsahy, nájdete pri službe Integrácie a automatizácia. Jedno napojenie medzi dvoma systémami tam začína od 18 000 Kč bez DPH.

Orientačný rozsah si môžete spočítať v kalkulačke. Keď chcete checklist prejsť rovno nad vaším e-shopom, preberieme projekt na 30-minútovej konzultácii.