„QuickBooks“ alternatyvos, kai jums reikia API, o ne programos

Kodėl platformų komandos išauga „QuickBooks“, ko iš tikrųjų reikalauja požiūris „API, o ne programa“ ir kokios alternatyvos geriausiai tinka skirtingoms užduotims.

„QuickBooks Online“ yra funkcionali smulkiojo verslo buhalterinės apskaitos programa, turinti didelę vartotojų bazę, OAuth 2.0 REST API, „webhooks“ palaikymą ir plačią kūrėjų ekosistemą. Dauguma komandų, ieškančių alternatyvos, neturi priekaištų pačiai programai. Jos susiduria su kitokia problema: joms reikia, kad buhalterinę apskaitą (books) tvarkytų programinė įranga, o ne žmogus, tuo tarpu „QuickBooks“ sukurta remiantis prielaida, kad tai daro žmogus.

Šis straipsnis yra apie šį neatitikimą ir ką vertėtų naudoti vietoje to. Jei esate smulkusis verslas ir renkatės buhalterinės apskaitos programą, „QuickBooks“ greičiausiai yra teisingas pasirinkimas, ir niekas iš to, kas čia parašyta, jums netaikoma.

Kur išryškėja šis neatitikimas

Vienas API ryšys – vienas įmonės failas. „QuickBooks“ API yra susietas su konkrečia įmone, identifikuojama pagal sritį (realm). Platforma, kuriai reikia tvarkyti apskaitą 300 pardavėjų įmonių, turi valdyti 300 prisijungimų ir 300 prenumeratų, o ne vieną paskyrą su 300 įmonių joje. Būtent šis faktas dažniausiai užbaigia alternatyvų vertinimo procesą.

API tėra programos priedas, o ne pagrindinis produktas. Funkcijos pirmiausia atsiranda vartotojo sąsajoje, o API jas pasiekia pagal atskirą tvarkaraštį. Kai visa jūsų integracija priklauso nuo to, ar funkcija gali būti iškviesta per API, teiginys „prieinama programoje“ nereiškia, kad ji iš tiesų prieinama.

Užklausų ribojimas (throttling) pritaikytas duomenų sinchronizavimui, o ne operacijų srautui. „QuickBooks“ limitai, kaip dažnai dokumentuojama, yra 500 užklausų per minutę vienai įmonei, o paketiniams (batch) ir ataskaitų galiniams punktams (endpoints) taikomi dar griežtesni apribojimai; dabartinius skaičius vertėtų pasitikrinti oficialioje „Intuit“ kūrėjų dokumentacijoje. Tai yra dosnu, kai reikia sinchronizuoti vieno verslo įrašus, tačiau visai kas kita, kai jūsų platforma realiuoju laiku registruoja tūkstančių įmonių operacijas.

Yra spragų ES tarpvalstybinių mokesčių apskaitoje. Pačios „Intuit“ pagalbos medžiagoje nurodoma, kad nėra standartinės procedūros IOSS PVM apskaityti per „QuickBooks“, ir vartotojams siūloma kreiptis į buhalterį ar apskaitininką. Platformai, kuri vykdo prekybą skirtingose ES šalyse, nuotolinės prekybos ir OSS tvarkymas nėra tik reta išimtis, todėl prieš pradedant kurti integraciją verta tai pasitikrinti atsižvelgiant į jūsų konkrečias šalis.

Nė vienas iš šių dalykų nėra defektas. Tai yra tiesiog puikios programos, skirtos verslui, samdančiam buhalterį, kūrimo pasekmės.

Ko iš tikrųjų reikalauja „API, o ne programa“

Prieš lyginant alternatyvas, pravartu įvardyti, ko platformų komandos iš tikrųjų ieško, nes kriterijų „turi API“ atitinka beveik visos sistemos.

Visiškas padengimas. Visas programos funkcijas galima iškviesti per API. Šiuo klausimu „Nordlet“ pozicija yra tokia: programa neturi jokių privačių galinių punktų — vartotojo sąsaja veikia per tuos pačius iškviesties taškus, kurie prieinami ir išoriniams naudotojams.
Daugelio įmonių valdymas vienoje paskyroje. Daugelio subjektų apskaita be daugybės prenumeratų.
Idempotentiniai įrašymai. Pakartota užklausa negali sukurti antros sąskaitos faktūros arba dubliuojančio dvejybinio įrašo (journal entry).
Įvykių pristatymas. „Webhooks“, kurie suveikia pasikeitus būsenai, todėl jūsų sistema reaguoja į įvykius, o ne nuolat tikrina (polls) būseną.
Užtikrinami apskaitos invariantai. Nesubalansuoti įrašai atmetami, uždaryti laikotarpiai (closed periods) užrakinami, užregistruoti dokumentai tampa neredaguojami.
Mokesčiai kaip duomenys, o ne kaip ekranas. Tarifai, prekių ar paslaugų teikimo vietos sprendimai, validavimo rezultatai ir registrai pasiekiami programiniu būdu.
Testavimo aplinka (sandbox), atitinkanti gamybinę aplinką, ir neribotas testinių įmonių skaičius, kad integracijos testai būtų pigūs.

Vertinkite bet kokią alternatyvą pagal šį sąrašą, o ne pagal funkcijų matricą.

Alternatyvos pagal tai, ką bandote pasiekti

Jūsų situacija	Rinkitės	Kodėl
Jūsų platforma turi tvarkyti daugelio nuomininkų (tenants) apskaitą	Integruotą (embedded) buhalterinės apskaitos API, tokią kaip „Nordlet“	Daugelio įmonių valdymas vienoje paskyroje, apmokėjimas pagal sunaudojimą (metered pricing), apskaitos taisyklės užtikrinamos serverio pusėje
Jūsų klientai tvarko apskaitą per „QuickBooks“ ir jūs integruojatės su jais	Likite prie „QuickBooks“ API arba naudokite agregatorių	Apskaita priklauso klientui; priderinti integraciją prie jų yra teisingas sprendimas
Jums reikia prieigos prie apskaitos duomenų keliose apskaitos programose vienu metu	Agregatorių, tokį kaip „Codat“, „Rutter“ ar „Merge“	Viena sąsaja, jungianti daugybę skirtingų sistemų
Jums reikia e. piniginės likučių realiuoju laiku, o ne oficialios buhalterinės apskaitos	Didžiosios knygos infrastruktūrą, tokią kaip „Modern Treasury Ledgers“	Sukurta dideliam pralaidumui ir duomenų nekintamumui, o ne mokesčių deklaravimui
Norite vienos bendros sistemos operacijoms ir finansams	ERP, tokią kaip „Odoo“	Platus funkcionalumas mainais į tai, kad sistemą teks prižiūrėti patiems
Esate smulkusis verslas ir turite buhalterį	„Xero“, „QuickBooks“ arba vietinį atitikmenį	Programa ir yra tai, ko jums reikia

Integruota buhalterinės apskaitos API

Tai yra tiesioginis atsakymas į klausimą „API, o ne programa“. Buhalterinės apskaitos sistema tampa fonine (backend) paslauga, į kurią kreipiasi jūsų produktas, o jūsų vartotojai niekada nemato didžiosios knygos (general ledger).

„Nordlet“ ir yra sukurta būtent šiam modeliui: nekintanti dvejybinio įrašo didžioji knyga, kurios balansą užtikrina duomenų bazės trigeriai patvirtinimo (commit) metu, nuoseklus dokumentų numeravimas, laikotarpių užrakinimas, kuris su 409 kodu atmeta įrašus, datuotus uždarytame mėnesyje, kiekvieno pakeitimo audito žurnalas, palaikymas parametrui Idempotency-Key, kuris pakartotinės užklausos atveju grąžina išsaugotą atsakymą, bei pasirašyti „webhooks“, įrašomi į transakcinę siunčiamųjų pranešimų dėžutę tos pačios duomenų bazės operacijos metu kaip ir pats pakeitimas. Kainodara paremta realiu sunaudojimu, o ne apmokestinama už kiekvieną įmonę atskirai: nuo 10 € per mėnesį, įskaičiuojant 3 000 užklausų, ir su neribotu įmonių, vartotojų bei testinių įmonių (sandbox) skaičiumi kiekviename plane.

Atvirai apie apribojimus: „Nordlet“ teikia ankstyvąją prieigą ir šiuo metu priima pirmuosius dizaino partnerius; ES PVM funkcionalumas apima kiekvienos šalies tarifus, VIES validavimą ir OSS / IOSS deklaracijų skaičiavimą, tačiau vietinių mokesčių deklaracijų paketai šiuo metu palaikomi tik trims šalims – Lietuvai (FR0600), Vokietijai (UStVA) ir Lenkijai (JPK_V7M), o darbo užmokesčio apskaita pritaikyta tik Lietuvai.

Agregatoriai

„Codat“, „Rutter“ ir „Merge“ suteikia vieną bendrą sąsają su ta buhalterinės apskaitos sistema, kurią kiekvienas jūsų klientas jau naudoja. Jei jūsų produkto užduotis yra nuskaityti ar įrašyti duomenis į klientų buhalterinę apskaitą – pvz., skolinimas, išlaidų valdymas, analitika – tai yra teisinga kategorija, o integruota didžioji knyga būtų netinkamas pasirinkimas. Tačiau, jei jūsų platforma pati turi būti pagrindinė įrašų sistema, agregatorius tam netiks.

Didžiosios knygos infrastruktūra

Šios kategorijos produktai nekintamai stebi likučius su dideliu pralaidumu, tačiau neatlieka oficialios buhalterinės apskaitos. Jie puikiai tinka e. piniginių ar mokėjimų produktams, tačiau PVM apskaitą, sąskaitų faktūrų išrašymą ir metines ataskaitas jie palieka kitoms sistemoms.

ERP

„Odoo“ ir panašūs programų paketai apima kur kas daugiau verslo procesų nei tik apskaitą. Kompromisas, su kuriuo susiduria platformų kūrėjai, yra integracijos paviršius: išorinis „Odoo“ API veikia duomenų modelio lygmenyje per RPC, jo dokumentacijoje nurodoma, kad API prieiga apsiriboja „Custom“ kainodaros planu, o dabartinius RPC galinius punktus planuojama pakeisti naujesniu JSON API. Tai išsamiau aptariama straipsnyje „Nordlet“ ir „Odoo“ palyginimas platformų kūrėjams.

Jei migruojate iš „QuickBooks“

Keli dalykai, kurie visada užtrunka ilgiau nei tikėtasi:

Sąskaitų plano (Chart of accounts) atvaizdavimas (mapping). Atlikite tai labai atidžiai ir išsaugokite senąjį sąskaitos kodą kaip nuorodos laukelį naujojoje sąskaitoje. Jo prireiks, kai kas nors paklaus, kodėl pasikeitė palyginamasis rodiklis.
Pradiniai likučiai. Migruokite juos kaip likučius atskaitos datai, o ne registruodami visą istorinę operacijų eigą. Geriau palikite senąją sistemą prieinamą skaitymui per visą saugojimo laikotarpį, užuot bandę perkelti kelerių metų istorijos įrašus.
Dokumentų numeravimas. Nuspręskite, ar naujos serijos tęs senąją numeraciją, ar prasidės iš naujo, ir prieš pasirinkdami patikrinkite, kokie reikalavimai galioja jūsų jurisdikcijoje.
Atvirosios pozicijos (Open items). Neapmokėtos sąskaitos faktūros, nepanaudoti kreditai ir iš dalies sutapdinti mokėjimai turi būti perkeliami kaip atvirosios pozicijos, o ne kaip grynieji likučiai, kitaip vėliau neveiks sudengimas (reconciliation).
Mokestiniai laikotarpiai. Nemigruokite įpusėjus mokestiniam laikotarpiui, nebent esate pasirengę teikti vieną deklaraciją iš dviejų sistemų.
Vieną ciklą naudokite abi sistemas. Prieš išjungdami senąją sistemą, užregistruokite to paties mėnesio duomenis abiejose sistemose ir palyginkite bandomąjį balansą (trial balance).

D.U.K.

Ar yra nemokama „QuickBooks“ alternatyva?

Yra nemokamų ir atvirojo kodo apskaitos sistemų, o „Odoo“ siūlo nemokamą planą, ribojamą viena programa. Platformoms nemokamas sprendimas retai kada išlieka nemokamas, nes kaštai persikelia į prieglobą, atnaujinimus, atitikties pakeitimus ir inžinerinį laiką, reikalingą integracijos palaikymui. Vertinkite bendrą kainą, o ne licenciją.

Kas prekyvietei (marketplace) tinka labiau nei „QuickBooks“?

Kalbant konkrečiai apie prekyvietės apskaitą, integruota buhalterinės apskaitos API yra struktūriškai pranašesnis pasirinkimas, nes ji gali tvarkyti daugelio subjektų apskaitą vienoje paskyroje, užtikrinti apskaitos taisykles serverio pusėje ir būti valdoma išskirtinai jūsų programinės įrangos. „QuickBooks“ išlieka geresniu produktu vienam verslui, samdančiam buhalterį.

Ar „QuickBooks“ turi API programuotojams?

Taip. „QuickBooks Online“ siūlo OAuth 2.0 REST API kartu su „webhooks“ palaikymu ir kūrėjų portalu. Platformų integracijos apribojimas kyla ne dėl API kokybės, o dėl jo aprėpties: jis sukurtas integruotis su įmonės apskaita, o ne veikti kaip pagrindinė didžioji knyga kito produkto viduje.

Ar galiu pasilikti „QuickBooks“ ir pridėti buhalterinės apskaitos API?

Taip, galite, ir kai kurios komandos taip daro: pačios platformos apskaita tvarkoma integruotoje didžiojoje knygoje, o per integracijas suvestiniai žurnalų įrašai siunčiami į tą buhalterinės apskaitos sistemą, kurią naudoja konkretus verslo klientas. Pagrindinė taisyklė, kurios reikia laikytis, yra ta, kad kiekvienai apskaitos knygų sekai turi būti lygiai viena pagrindinė įrašų sistema. Dvi sistemos, kurios abi laikomos oficialiais šaltiniais, yra tiesiausias kelias į duomenų sudengimo problemas.

O kaip dėl „Xero“ alternatyvos?

Kaip programa, „Xero“ yra stipri alternatyva ir turi puikiai aprašytą API dokumentaciją, tačiau jos struktūrinis modelis yra toks pat: prenumeratos ir API limitai taikomi vienai organizacijai, o nesertifikuotoms programoms taikomas maksimalus 25 prijungtų organizacijų limitas. Šis palyginimas pateikiamas straipsnyje „Nordlet“ ir „Xero“ palyginimas integruotai apskaitai.