Valkostir við QuickBooks þegar þig vantar API en ekki smáforrit

Af hverju teymi vaxa upp úr QuickBooks, hvað það þýðir í raun að vera með API en ekki smáforrit, og hvaða valkostir henta í hvaða verkefni.

QuickBooks Online er fært bókhaldsforrit fyrir lítil fyrirtæki með stóran notendagrunn, OAuth 2.0 REST API, vefkróka (webhooks) og öflugt þróunarumhverfi. Flest teymi sem leita að valkosti eru ekki óánægð með forritið sjálft. Þau hafa lent í öðru vandamáli: þau þurfa hugbúnað, ekki manneskju, til að halda bókhaldið, og QuickBooks er hannað út frá þeirri forsendu að manneskja sjái um það.

Þessi grein fjallar um þetta misræmi og hvað skuli nota í staðinn. Ef þú ert smáfyrirtæki að velja bókhaldshugbúnað gæti QuickBooks verið hið rétta svar og ekkert af þessu á við um þig.

Hvar misræmið kemur í ljós

Ein API-tenging er ein fyrirtækjaskrá. API-ið frá QuickBooks miðast við eitt fyrirtæki sem auðkennt er með kerfissvæði (realm). Vettvangur sem þarf bókhald fyrir 300 seljendaeiningar er að sýsla með 300 tengingar og 300 áskriftir, ekki einn aðgang með 300 fyrirtækjum innan sinna vébanda. Þessi staðreynd ein og sér bindur yfirleitt enda á mat ferlisins.

API-ið er viðauki við forritið, ekki varan sjálf. Eiginleikar birtast í viðmótinu og rata inn í API-ið á sínum eigin hraða. Þegar öll samþætting þín reiðir sig á að hægt sé að kalla í ákveðna virkni er „í boði í forritinu“ ekki það sama og að það sé aðgengilegt.

Takmarkanir á beiðnum (throttling) eru hannaðar fyrir samstillingu, ekki færsluflæði. Mörk QuickBooks eru skráð með almennum hætti sem 500 beiðnir á mínútu fyrir hvert fyrirtæki, með þrengri mörkum á hóp- og skýrsluendapunka; staðfestu nýjustu tölur gagnvart þróunargögnum Intuit sjálfra. Það er ríflegt þegar verið er að samstilla færslur eins fyrirtækis en allt annar handleggur þegar vettvangurinn þinn bókar færslur fyrir þúsundir fyrirtækja í rauntíma.

Skattar yfir landamæri innan ESB eru með gloppur. Stuðningsgögn Intuit sjálfra taka fram að engin staðalaðferð sé til við bókhald IOSS-virðisaukaskatts í QuickBooks og vísa notendum á bókara eða endurskoðanda. Fyrir vettvang sem selur yfir landamæri innan ESB er meðhöndlun á fjarsölu og ráðstöfunum í gegnum eina stöð (One Stop Shop) ekki jaðartilvik, svo það borgar sig að staðfesta þetta fyrir þínar tilteknu lönd áður en haldið er í smíðar.

Ekkert af þessu eru gallar. Þetta eru afleiðingar þess að smíða frábært forrit fyrir fyrirtæki sem hafa bókara í vinnu.

Hvað "API, ekki smáforrit" krefst í raun og veru

Áður en valkostir eru bornir saman er gagnlegt að nefna það sem teymi á vettvangi eru í raun að biðja um, enda uppfylla nánast öllkerfi kröfuna um að „vera með API“.

Full þekking. Allt sem forritið getur gert er hægt að kalla á. Afstaða Nordlet hér er sú að forritið sé ekki með neina lokaða endapunkta - viðmótið keyrir á sömu endapunktum og utanaðkomandi kallar fá.
Mörg fyrirtæki undir einum aðgangi. Bókhald fyrir margar einingar án margra áskrifta.
Sjálfkvæmar ritanir (idempotent writes). Endurtekin beiðni getur ekki búið til annan reikning eða tvítekið færslubókartilfærslu.
Atburðaskilun. Vefkrókar (webhooks) sem kvikna við breytingar á stöðu, svo kerfið þitt bregðist við í stað þess að spyrja stöðugt frétta (poll).
Framfylgdar bókhaldsreglur. Ójafnvægi í færslum hafnað, lokuðum tímabilum læst, og birtum skjölum óbreytanlegum.
Skattar sem gögn, ekki sem skjámynd. Hægt er að nálgast skatthutföll, ákvarðanir um staðsetningu afhendingar, staðfestingarniðurstöður og skrár með forritun.
Prófunarumhverfi (sandbox) sem endurspeglar framleiðsluumhverfið, og ótakmörkuð prófunarfyrirtæki þannig að samþættingarpróf séu ódýr.

Metið hvaða valkost sem er gegn þeim lista í stað eiginleikafylkis.

Valkostirnir, flokkaðir eftir því hvað þú ert að reyna að gera

Aðstæður þínar	Veldu	Af hverju
Vettvangurinn þinn þarf að eiga bókhald margra leigjenda	Innbyggt bókhalds-API eins og Nordlet	Mörg fyrirtæki undir einum aðgangi, mæld verðlagning, bókhaldsreglum framfylgt meginstegin
Viðskiptavinir þínir halda bókhald í QuickBooks og þú samþættist þeim	Vertu á QuickBooks API, eða notaðu samlögunarþjónustu	Bókhaldinu tilheyrir viðskiptavinurinn; að hitta þá þar er rétt
Þig vantar bókhald í nokkrum bókhaldsforritum í einu	Samlögunarþjónustu (aggregator) eins og Codat, Rutter eða Merge	Eitt viðmót þvert á mörg undirliggjandi kerfi
Þig vantar rauntímastöðu veskja, ekki lagalegt bókhald	Höfuðbóksinnviði (ledger infrastructure) eins og Modern Treasury Ledgers	Hannað fyrir afköst og óbreytanleika, ekki skattskil
Þig vantar eitt kerfi yfir rekstur og fjármál	ERP kerfi eins og Odoo	Víðfeðmi, á kostnað þess að reka það sjálfur/sjálf
Þú ert smáfyrirtæki með bókara	Xero, QuickBooks eða staðbundið samsvarandi kerfi	Forritið er tilgangurinn

Innbyggt bókhalds-API

Þetta er beina svarið við „API, ekki smáforrit“. Bókhaldskerfið verður bakendaþjónusta sem varan þín kallar á, og notendur þínir sjá aldrei höfuðbók.

Nordlet er hannað fyrir þetta form: óbreytanleg tvíþætt höfuðbók þar sem jafnvægi ertryggt með gagnagrunnskveikju á ákvörðunarstundu (commit), eyðulaus skjalaniðurstöðunúmerun, læsing tímabila sem hafnar færslum dagsettum innan lokaðs mánaðar með villukóðanum 409, endurskoðunarslóð á hverri breytingu, stuðningur við Idempotency-Key sem spilar geymdu svörin aftur við endurtilraun, og undirritaðir vefkrókar skrifaðir í færsluútgangsskrá (transactional outbox) í sömu gagnagrunnsfærslu og breytingin. Verðlagning er mæld í stað þess að miðast við fyrirtæki: frá €10 á mánuði með 3.000 beiðnum inniföldum, ásamt ótakmörkuðum fyrirtækjum, notendum og prófunarfyrirtækjum í öllum áskriftum.

Heiðarleg takmörkun: Nordlet er í snemmtækum aðgangi (early access) og hönnunarsamstarfi; virðisaukaskattur innan ESB nær yfir skatthutföll eftir löndum, VIES-staðfestingu og útreikning á OSS/IOSS skýrslum, en innlend skattskilaforrit eru tilbúin fyrir þrjú lönd í dag - Litháen (FR0600), Þýskaland (UStVA) og Pólland (JPK_V7M), og launavinnsla er eingöngu fyrir Litháen.

Samlögunarþjónustur (Aggregators)

Codat, Rutter og Merge gefa þér eitt viðmót inn í hvaða bókhaldskerfi sem er sem hver viðskiptavinur notar fyrir. Ef hlutverk vörunnar þinnar er að lesa eða skrifa bókhald viðskiptavina þinna - útlán, útgjaldastýring, greiningar - er þetta rétti flokkurinn og innbyggð höfuðbók væri röng. Ef vettvangurinn þinn þarf að vera upprunakerfið (system of record), þá getur samlögunarþjónusta ekki verið það.

Höfuðbóksinnviðir

Vörur í þessum flokki halda utan um stöður með óbreytanlegum hætti og miklum afköstum án þess að sinna lögbundnu bókhaldi. Þær passa vel undir veski eða greiðsluvöru og skilja virðisaukaskatt, innheimtu og ársskýrslur eftir hjá einhverju öðru.

ERP kerfi

Odoo og svipaðir pakkar ná yfir mun stærri hluta rekstursins en bókhald. Málamiðlunin fyrir hönnuði vettvanga er samþættingaryfirborðið: ytra API Odoo virkar á gagnamódelstigi yfir RPC, skjöl þess taka fram að API-aðgangur sé takmarkaður við Custom-verðlagningarþrepið, og núverandi RPC endapunktar eiga að vera skiptir út fyrir nýrra JSON API. Það er fjallað um þetta í Nordlet vs Odoo fyrir hönnuði vettvanga.

Ef þú ert að flytja frá QuickBooks

Nokkrir hlutir sem taka áreiðanlega lengri tíma en búist er við:

Kortlagning bókhaldslykla. Gerðu það markvisst og geymdu gamla reikningskóðann sem tilvísunarreit á nýja reikningnum. Þú munt þurfa á honum að halda þegar einhver spyr hvers vegna samanburðartala hafi færst til.
Upphafstöður. Flyttu inn sem stöður á afmörkunardagsetningu, ekki sem endurbirtar færslur. Hafðu gamla kerfið lesanlegt yfir varðveislutímabilið í stað þess að reyna að spila margra ára færslur aftur.
Skjalanúmerun. Ákveðdu hvort nýjar raðir haldi áfram gömlu númeruninni eða byrji upp á nýtt, og athugaðu kröfur í þínu lögsögusvæði áður en þú velur.
Opin atriði. Ógreiddir reikningar, ónotaðar inneignir og að hluta til jafnaðar greiðslur þurfa að koma inn sem opin atriði, ekki sem nettóstaður, annars virkar afstemmingin ekki á eftir.
Skattatímabil. Ekki flytja miðsvæðis á tímabili nema þú sért tilbúinn/-ur til að skila einni skýrslu úr tveimur kerfum.
Keyrðu bæði í eina lotu. Bókaðu sama mánuð í báðum og berðu saman reynslujöfnuð (trial balance) áður en þekkja skal gamla kerfið af.

FAQ

Er til ókeypis valkostur við QuickBooks?

Það eru til ókeypis bókhaldskerfi með opnum kóða, og Odoo gefur út ókeypis þrep sem takmarkast við eitt forrit. Ókeypis er sjaldan ókeypis til lengri tíma fyrir vettvang, því kostnaðurinn færist yfir í hýsingu, uppfærslur, samræmi við regluverk og verkfræðitíma til að halda samþættingu gangandi. Verðleggðu heildarmyndina, ekki leyfið.

Hvað er betra en QuickBooks fyrir markaðstorg?

Sérstaklega fyrir bókhald markaðstorgs er innbyggt bókhalds-API betri uppbygging, vegna þess að það getur haldið bókhald fyrir margar einingar undir einum aðgangi, framfylgt bókhaldsreglum meginstegin og stjórnast alveg af hugbúnaðinum þínum. QuickBooks er enn þá betri vara fyrir eitt fyrirtæki með bókara.

Er QuickBooks með API fyrirforritara?

Já. QuickBooks Online býður upp á OAuth 2.0 REST API með vefkrókum og þróunargátt. Skorðan við notkun á vettvangi er ekki gæði API-ið heldur gildissvið þess: það er hannað til að samþættast bókhaldi fyrirtækis, ekki til að vera höfuðbókin innan annarrar vöru.

Get ég haldið QuickBooks og bætt við bókhalds-API?

Það máttu gera, og sum teymi gera það: eigin bókhaldi vettvangsins er haldið í innbyggðri höfuðbók, á meðan samþættingar ýta samantektarfærslum yfir í hvaða bókhaldskerfi sem viðskiptavinur hvers fyrirtækis notar. Reglan sem skal fylgja er sú að nákvæmlega eitt kerfi sé upprunakerfið fyrir tiltekið bókhaldsset. Tvö kerfi sem bæði segjast vera hin sannleikskvafrið eru upphafið að vandamálum í afstemmingum.

Hvað með Xero í staðinn?

Xero er sterkur valkostur sem forrit og er með vel skjalað API, en það hefur sömu skipulagsbyggingu: áskriftir og API-mörk eru á hverja stofnun og óvottuð forrit eru takmörkuð við 25 tengdar stofnanir. Samanburðurinn er settur fram í Nordlet vs Xero fyrir innbyggt bókhald.