Hvernig á að samþætta bókhaldsskýja-API við SaaS vettvang

Handbók þróunaraðila um hvernig byggja má upp bókhaldssamþættingu fyrir marga leigjendur sem þolir OAuth, vefboð, skattareglur og samhæfingu án þess að spilling verði í bókhaldinu.

Flest teymi sem setja sér það markmið að „bæta við bókhaldi“ í SaaS-vöruna sína byrja á því að tengja HTTP biðlara (client) við endapunkt veitunnar og senda inn reikning. Það virkar í kynningu. Það koðnar niður í fyrsta sinn sem viðskiptavinur tengir saman tvær bókhaldseiningar, í fyrsta sinn sem vefboð (webhook) berst tvisvar og í fyrsta sinn sem endurnýjunarlykill (refresh token) snýst og glatast miðju ferli. Varanlegri útgáfan af þessari vinnu er ekki einfaldur biðlari, heldur samþættingarlag.

Þetta lag þarf að sjá um leigjendatengingar (tenant connections), vistun og snúning lykla, bókhaldsreglur sem tilheyra hverri veitu fyrir sig, gagnavörpun (record mapping), upphafs- og viðbótarsamstillingu, innlestur vefboða ásamt endurtilraunum og afritunarhreinsun, hraðatakmarkanir (rate limits), útgáfustýringu og endurskoðunarslóð (audit trail) sem þjónustudeildin þín getur lesið klukkan tvö um nóttina. Þessi grein fer yfir þessa arkitektúr og þær ákvarðanir sem skipta mestu máli.

Gagnleg hugmyndalíkan:

SaaS-vara → þjónusta fyrir bókhaldssamþættingu → millistykki veitu (eða sameinað API) → ósamstillt samstilling og samhæfing

Bókhaldskerfið er áfram uppspretta sannleikans (system of record) fyrir bókhaldsfærslur: reikninga, skattakóda, bókaðar færslur og dagbókarfærslur. SaaS-vettvangurinn þinn heldur utan um stöðug kerfisskilkenni (cross-system identifiers), samstillingarstöðu, vörpunarmetagögn og rekstrarlegt endurskoðunarskeið.

Hvað „bókhaldsskýja-API“ þýðir raunverulega í þessu samhengi

Þessi setning vísar venjulega til API-viðmóts hýsts bókhaldsvettvangs eins og QuickBooks Online, Xero, Sage, Zoho Books eða svæðisbundins kerfis. Hún getur einnig þýtt sameinað bókhalds-API sem staðlar fleiri en eina veitu undir einu viðmóti.

Það borgar sig að vera nákvæmur, þar sem útfærslan er mismunandi eftir markmiðum. Að lesa reikninga vegna skýrslugerðar er ekki sama verk og að búa til reikninga út frá SaaS-virkni, bóka aðkeyptar þjónustur/vörur, samstilla viðskiptavini og vörur, skrifa dagbókarfærslur eða keyra sanna tvíhliða samstillingu. Ákveðið hvað af þessu þið eruð að smíða áður en þið snertið á endapunkti.

Ein aðgreining til viðbótar skiptir máli fyrir þessa grein. Greiðslu-API flytur peninga. Banka-API sækir gögn um reikninga. Reikningagerðar-API getur búið til skjöl án þess að opna aðalbókina. Innbyggð bókhaldsbók (embedded accounting ledger) er annað mál: SaaS-fyrirtækið á sjálfa bókhaldsvélina. Þessi síðasta nálgun er þar sem Nordlet staðsetur sig. Í stað þess að tengja vöruna þína við ytri bókhaldsbók viðskiptavinar veitir Nordlet vettvangi og markaðstorgum raunverulegar tvíhliða bókhaldsbækur, óbreytanlega endurskoðunartilbúna höfuðbók, meðhöndlun ESB-virðisaukaskatts og útborganir inn í þeirra eigin vöru, í gegnum API-fyrst hönnun með sláttustýrðum (typed) SDK-um og vefboðum. Ef þú ert á markaðstorgi að ákveða hvort samþætta eigi bókhaldskerfi viðskiptavinar eða reka bókhaldið sjálf/ur, þá er það raunveruleg krossgata og við munum koma aftur að því.

Fjelleigendastaða (multi-tenancy): afmarkaðu hverja tengingu tvisvar

Í SaaS-vöru tengist eitt forrit mörgum skipulagsheildum viðskiptavina. Hver tenging verður að vera afmörkuð bæði af SaaS-leigjandanum og auðkenni skipulagsheildar veitunnar, svo sem Xero leigjendaauðkenni (tenant ID) eða QuickBooks svæðisauðkenni (realm ID).

Ekki nota OAuth notandaauðkennid eitt og sér sem lykil að tengingum. Einn notandi getur heimilað aðgang að nokkrum bókhaldseiningum og sami aðili getur endurtengt skipulagsheild gegnum mismunandi notendur með tímanum. Ef þetta fer úrskeiðis muntu að lokum bóka reikning eins viðskiptavinar inn í bókhald annars viðskiptavinar, og það er ekki villa sem hægt er að jafna sig á í hljóði.

Fyrsta arkitektúrákvörðunin: Beint tengistykki, sameinað API eða innbyggð höfuðbók

Beinar veitusamþættingar

Bein samþætting veitir þér mesta stjórn: eiginleika sem eru bundnir tilteknum veitum, sérsniðna reiti, villumeðhöndlun, samstillingartíðni, varðveislu gagna og kostnaðarskipan. Verðið er þó raunverulegt. Hver veita kemur með sitt eigið OAuth-flæði, gagnagrunnsskipulag, sérvisku, hraðatakmarkanir, hegðun vefboða, vottun og áframhaldandi viðhald.

Sameinuð bókhalds-API

Sameinað API býður upp á eitt viðmótt yfir nokkur bókhaldskerfi og staðlar einingar eins og viðskiptavini, reikninga, birgja, reikninga (accounts), greiðslur og vörur. Það getur stytt upphaflegan byggingartíma. Það fjarlægir þó ekki flókið samþættingarferli, og það er algeng villa að koma fram eins og það geri það.

Áður en ákvörðun er tekin skal spyrja: Hvaða veitur og aðgerðir eru studdar? Virka skrifaðgerðir, eða eingöngu lestur? Eru skrifaðgerðir samstilltar (synchronous) eða í biðröð? Eru sértækir reitir veitu aðgengilegir í gegnum endarsendingu (passthrough)? Er gögnum skyndiminnið (cached) og hversu nýleg eru þau? Hver sér um bilanir hjá veitu og breytingar á API? Er verðlagningin á hvert kallið, á hvern tengdan reikning, á hverja færslu eða fast gjald fyrir vettvanginn? Geturðu flutt út vörpun þína og aftengt á hreinan hátt? Orðið „sameinað“ þýðir sjaldnast „með sömu eiginleika á milli allra veita“.

Innbyggð höfuðbók (embedded ledger)

Ef kjarnavandamál vettvangsins þíns snýst um að reka bókhaldið fyrir notendur þína, frekar en að endurspegla það í núverandi bókhaldsbókum þeirra, þá breytir innbyggð höfuðbók jöfnunni. Markaðstorg með þúsundum seljenda, eða SaaS-vara sem þarf innbyggða, endurskoðunartilbúna VSK-meðhöndlun innan ESB og samræmi miðað við lönd, fær meira út úr því að eiga sjálfa bókhaldsvélina heldur en að tengja N ytri tengistykki. Það er staðsetning Nordlet: raunverulegar bækur sem API, óbreytanlegt tvíhliða bókhald, VSK eftir löndum með VIES-staðfestingu og gerð i.SAF-skrár, SEPA-útflutningur og skýrsluútflutningur á XLSX-, PDF- eða JSON-sniði, allt innan þinnar eigin vöru í stað þess að fara í gegnum þriðja aðila.

Ákvörðunarregla sem ég nota:

Aðstæður	Besti kostur
Eitt bókhaldskerfi drottnar yfir viðskiptavinahópnum þínum; hegðun sem er bundin við veituna skiptir sköpum	Beint tengistykki
Breið þekja á veitum og hraði á markað skipta máli umfram stjórn	Sameinað API
Þú ert vettvangur eða markaðstorg sem þarf að reka og eiga bókhaldið, með VSK í ESB og endurskoðunarslóð	Innbyggð höfuðbók (Nordlet)
Blandnar aðstæður	Blandað: sameinað fyrir algeng flæði, beina tengistykki fyrir stefnumótandi veitur

Ráðlagður arkitektúr samþættingar

Einangraðu samþættinguna frá kjarnaviðskiptarökfræði

Ekki dreifa kalli í veitu á milli innheimtu, pantana, áskrifta og skýrslugerðar. Smíðaðu sérstaka samþættingarþjónustu sem heldur utan um millistykki veitu, umsjón með OAuth-tengingum, staðlaðar gerðir (canonical models), auðkennisvörpun, samstillingarverk og biðraðir, veitendaendapunkta, endurtilraunir og meðhöndlun dauðra skilaboða (dead-letter handling), endurskoðunarslóð og samhæfingartæki. Þetta kemur í veg fyrir að heiti á reitum frá Xero eða QuickBooks leki inn í lénslíkanið þitt (domain model).

Skilgreindu þröngt og staðlað líkan (canonical model)

Líkaðu aðeins þau verkflæði sem þú styður. Dæmigerðir hlutir: viðskiptavinur, vara eða þjónustuliður, reikningur, reikningslína, greiðsla, kreditnóta, birgir, reikningur í bókhaldi, skatthlutfall, gjaldmiðill, dagbókarfærsla.

Varðveittu greiningarmuni sem hafa áhrif á bókhaldið. Ekki fletja út drög á móti samþykktum á móti bókuðum færslum, upphæðum með eða án skatts, kreditnótum á móti neikvæðum reikningum, ráðstöfun greiðslu á móti tilvist greiðslu, eða reikningsnúmeri sem viðskiptavinur sér á móti auðkenni hlutar hjá veitu. Hver færsla ætti að bera með sér SaaS-auðkenni, auðkenni veitu, nafn veitu og útgáfu API, vísbendingu um uppruna sannleikans (source-of-truth indicator), stöðu, tímamerki, tíma síðustu samstillingar, ytri tilvísun og stöðu villa/samhæfingar.

Haltu úti skýrum vörpunartöflum (mapping tables)

Varpaðu SaaS-leigjanda á skipulagsheild í bókhaldi, SaaS-viðskiptavini á tengilið hjá veitu, SaaS-vöru á vöru eða reikning hjá veitu, SaaS-reikningi á reikning hjá veitu, SaaS-greiðslu á greiðslu hjá veitu, skattaflokki á skattakóda og tekjuflokki á höfuðbókarreikning.

Aldrei nota nöfn eða netföng sem varanleg auðkenni. Nöfn breytast, tvritanir (duplicates) eru til staðar og tveir viðskiptavinir geta deilt netfangi. Vistaðu óbreytanlegt auðkenni veitunnar og haltu upprunalegu SaaS-auðkenninu til haga.

Bættu við stöðuvélum (state machines)

Gefðu tengingu skýrar stöður: ekki tengd, heimildar biðst, tengd, upphafssamstillingar biðst, samstillir, heilbrigð, hraðatakmörkuð, endurheimildar krafist, veita ekki tiltæk, aftengd, bilað varanlega. Gefðu færslum sínar eigin stöður: í bið, send, staðfest, mistókst en má reyna aftur, mistókst og krefst aðgerðar frá notanda, samhæft, árekstur fannst. Tvöfaldur „tengd/ekki tengd“ fáni segir þjónustudeildinni þinni ekkert gagnlegt.

OAuth og uppsetning tenginga

Notaðu auðkenningarflæði með kóða (authorization code flow). Viðskiptavinurinn smellir á Tengja, netþjónninn þinn býr til skammlífa auðkenningarviðskiptaaðgerð (authorization transaction), viðskiptavinurinn auðkennir sig hjá veitunni og veitir heimildir (scopes), þú skiptir kóðanum út fyrir lykla, uppgötvar leyfisbundna skipulagsheild, vistar tenginguna gegn réttum leigjanda og setur upphafs-samstillingu í biðröð.

Staðfestu endurhringinguna (callback) vandlega: state á móti netþjónsmegin viðskiptaaðgerð, nákvæmt endursendislóð (redirect URI), útgefanda veitunnar og samhengi leigjandans. RFC 9700, OAuth 2.0 Security Best Current Practice, formfestir núverandi leiðbeiningar: notaðu PKCE með auðkenningarflæðum sem nota kóða, forðastu óbeina og lykilorðsinnskráningu og notaðu nákvæma samvinnu við endursendislóðir.

Biddu um lágmarksheimildir (least-privilege scopes). Notaðu aðeins lestur þar sem þ þarft ekki að skrifa. Heimildalíkön breytast, svo ekki afrita gömul dæmi. OAuth skjöl Xero benda á að breiðar bókhaldsheimildir séu að skiptast út fyrir fínkornóttar (granular) heimildir, þar sem ný forrit hafa fengið fínkornóttar heimildir úthlutaðar síðan í mars 2026 og breiðar heimildir munu vera tiltækar til september 2027.

Vistaðu lykla eingöngu megin á netþjóni. Ekki birta þá í vafraskriftum (browser JavaScript), smáforritum fyrir farsíma, vafra- eða forritaskrám (frontend logs), greiningartækjum eða villuboðum sem viðskiptavinir sjá. Dulkóðuðu í hvíld (at rest), fjarlægðu viðkvæmar upplýsingar úr annálum og haltu metagögnum per tengingu: dulkóðuðum aðgangs- og endurnýjunarlyklum, gildistíma, auðkenni skipulagsheildar hjá veitu, veittum heimildum, útgáfutíma, síðustu farsælu endurnýjun, afturköllunarstöðu.

Snúningur endurnýjunarlykla (refresh-token rotation) er þar sem framleiðsluumhverfið brestur

Endurnýjunarsvar gæti skilað nýjum endurnýjunarlykli. Þú verður að vista nýjasta gildið á óskiptanlegan hátt (atomically), annars lokarðu viðskiptavininum úti. Samkvæmt spurningum og svörum fyrir þróunaraðila hjá Xero, skilar hver endurnýjun nýjum endurnýjunarlykli, endurnýjunarlyklar gilda í allt að 60 daga og það er 30 mínútna frestur til að reyna aftur með núverandi lykli ef svar glatast. QuickBooks Online segir þróunaraðilum að geyma nýjasta endurnýjunarlykilinn úr nýjasta svari: endurnýjunarlyklar gilda í allt að 100 daga og gildið getur snúist eins oft og á 24 klukkustunda fresti.

Í framkvæmd: notaðu læsingu fyrir endurnýjun á hverja tengingu, skiptu um endurnýjunarlykil á óskiptanlegan hátt, meðhöndlaðu tímabundnar bilanir á lyklaendapunkti með endurtilraunum, birtu skýra stöðu endurheimildar og aldrei endurnýja á hverju einasta API-kalli á meðan gildur aðgangslykill er til staðar.

Upphafssamstilling (initial synchronization)

Keyrðu upphafssamstillingu sem bakgrunnsverk. Ekki blokka OAuth-endurhringinguna eða notendaviðmótið á því.

Örugg röð aðgerða: sækja metagögn skipulagsheildar, sækja reikninga, skatthlutfall, gjaldmiðla, tengiliði og vörur, vista auðkenni veitu og vörpun, flytja aðeins inn þann sögulega glugga sem varan þarf, setja háða hluti í biðröð í háðri röð (dependency order), skrá stöðukvarða (checkpoint) og merkja tenginguna heilbrigða aðeins eftir staðfestingu.

Háð röð skiptir máli. Reikningur gæti þurft á því að halda að tengiliður, vöruliður, tekjureikningur, skattakóði og gjaldmiðill séu til fyrir. Ekki búa til tvritanir í blindni. Paraðu saman á vistuðu ytri auðkenni, tilvísun sem viðskiptavinur gaf upp, skilgreindri pörunarreglu eða skýru vali notanda fyrir óljós tilfelli.

Viðbótarsamstilling (incremental synchronization)

Meðhöndlaðu vefboð sem merki, en ekki sem viðmiðunarrit sem gilda skilyrðislaust

Vefboð segja venjulega til um að eitthvað hafi breyst. Staðfestu undirskriftina, skráðu hráan atburð, skilaðu nauðsynlegu velgengnissvari hratt, hreinsaðu tvritanir, settu upp eftirfylgni í biðröð, sæktu núverandi hlut frá veitu, taktu við uppfærslunni á færslumiðuðum hátt (transactionally), uppfærðu stöðukvarðann og beindu bilunum í endurtilraun eða samhæfingu. Þetta meðhöndlar ófullkomna gagnapakka og atburði sem koma í rangri röð.

Reglur veitna eru mismunandi, svo ekki lofa einni almennri hegðun. Vefboð Xero bera HMAC-SHA256 undirskrift í x-xero-signaturehausnum, krefjast HTTPS, reyna aftur með minnkandi tíðni í allt að 24 klukkustundir, geta verið gerð óvirk eftir ítrekaðar bilanir og geta geymt atburði í allt að 31 dag til endurspilunar eftir endurheimt. QuickBooks Online staðfestir með HMAC-SHA256 og staðfestingarlykli (verifier token), býst við HTTP 200 innan þriggja sekúndna og reynir aftur á föstum tímaáætlunum sem síðar breytast í sex klukkustunda millibil, þar mælir Intuit með ósamstilltri vinnslu.

Afritunarhreinsun og sjálfvirk einstökuvinnslan (idempotency)

Afhending að minnsta kosti einu sinni (at-least-once delivery) er eðlileg. Búðu þig undir tvítekin vefboð, endurtilraunir eftir tímatakmörkun (timeout) þar sem skriftin tókst í raun, atburði í rangri röð og tvítekin smell frá notendum. Notaðu auðkenni atburðar frá veitu þar sem það er í boði, einstakan atburðarlykil í varanlegri geymslu, auðkenni aðgerðar sembúið er til fyrir hverja skrift, takmarkanir á einstakleika í gagnagrunni (uniqueness constraints), uppfærslu- og ísetningarskilmála (upsert semantics) og samhæfingarfyrirspurn eftir óljósar tímatakmarkanir.

Ekki gera ráð fyrir því að öll bókhalds-API bjóði upp á innbyggða sjálfvirka einstökuvinnslulykla (idempotency keys). Ef veitan gerir það ekki skaltu vista innri aðgerðarlykil og athuga hvort væntanlegur ytri hlutur sé þegar til áður en reynt er aftur. Mynstur frá Sjálfvirkum beiðnum Stripe og almennar leiðbeiningar um sjálfvirka einstökuvinnslu vefboða eiga vel við hér.

Könnun (polling) og greining breytinga

Paraðu vefboð við reglulega könnun. Vefboð verða gerð óvirk, seinka, glatast vegna rangra stillinga eða takmarkast við ákveðna hluti. Xero styður If-Modified-Since hausinn fyrir breytingar eftir UTC tímamerki, en skjöl þess vara við því að ekki hver breyting uppfærir UpdatedDateUTC, þannig að sumar að hluta til greiddar færslur og tengiliðareitir birtast ekki í gegnum þá síu. Gagnabreytingasafn QuickBooks Online (Change Data Capture) fylgist með breytingum frá síðustu 30 dögum, takmarkar svör við 1.000 hlutum, skilar eytt einingum með Deleted stöðu og virkar best með styttri könnunargluggum.

Vistaðu stöðukvarða (checkpoint) per veitu og per leigjanda og notaðu skarpa glugga (overlap windows). Biddu um breytingar frá því aðeins áður en síðasti stöðukvarði var tekinn og hreinsaðu síðan tvritanir eftir auðkenni veitu og útgáfu breytingar. Þetta ver gegn skekkjum í klukku (clock skew) og hlutarbilunum.

Gagnatrygging sem er sértæk fyrir bókhald

Þetta er sá hluti sem aðskilur virka samþættingu frá traustri samþættingu.

Skattahegðun er ekki útskiptanleg. Skjöl Xero benda á að reikningar, kreditnótur og innkaupapantanir sjálfgefið án skatts (tax-exclusive) þegar LineAmountTypes er óskilgreint, kvittanir og bankafærslur sjálfgefið með skatti (tax-inclusive) og handvirkar dagbækur sjálfgefið án skatts. Notaðu TaxType reitinn, en ekki nafn skatthlutfallssins. Aldrei gera ráð fyrir því að „20% VSK“ auðkenni skattakóda á einstakan hátt; það getur breyst eftir landi, tegund færslu, gildi dagsetningar og stillingum skipulagsheildar. Þetta er þar sem fjölþjóðlegur VSK í ESB verður dýr í meðförum í höndum, og þar sem innbyggð höfuðbók með innbyggðu samræmi fyrir hverju landi skilar sínu.

Notaðu aukastafi eða fasta nákvæmni (fixed-precision arithmetic) fyrir peninga, aldrei tvíundar fleytitölur (binary floating point). Vistaðu gjaldmiðilskóða og nákvæmni, einingarupphæð, magn, afslátt, skattupphæð, nettó, brúttó og gengi. Ákvektu skýrt hvort þú sendir upphæðir á línu-stigi og leyfir veitunni að reikna út samtölur, eða sendir fyrirfram reiknaða samtölu. Að blanda þessu saman býr til sléttunarvillur (rounding discrepancies) sem endurskoðandinn þinn mun finna.

Vísaðu í höfuðbókarreikninga eftir auðkenni veitu eða kóða, en ekki sýnilegu nafni. Staðfestu fyrir skrift að reikningar, skattakóðar, viðskiptavinir, vörur og gjaldmiðill séu virkir og studdir. Biluð skrift á reikningi er venjulega vörpunar- eða stillingarvandamál, en ekki tímabundið API-vandamál, þannig að notendaviðmótið ætti að útskýra lagfæringuna í stað þess að sýna „samstilling mistókst“.

Ekki gera ráð fyrir jafngildi hluta. „Greiðsla“ getur þýtt kvittun, ráðstöfun, innlögn, bankafærslu eða dagbókarfærslu. SaaS „áskrift“ passar kannski ekki snyrtilega við bókhaldslegan „reikning“. Skilgreindu bókhaldsatburðinn sem þú vilt tákna áður en þú velur API-hlut. Sjá skjöl Xero um greiðslur til að sjá hvernig ein veita útfærir þetta.

Hraðatakmarkanir og útgáfustýring

Takmarkanir eru venjulega bundnar leigjanda, skipulagsheild, forriti eða blöndu af þessu. Samkvæmt spurningum og svörum Xero um takmarkanir: fimm samtímabeiðnir per leigjanda, 60 á mínútu per leigjanda, 5.000 á dag per leigjanda og 10.000 á mínútu yfir allt forritið, með hausum fyrir eftirstandandi takmarkanir og Retry-After á 429 villum. QuickBooks Online skjalfestir 500 beiðnir á mínútu og 10 á sekúndu per svæðisauðkenni, með hóp-endapunkti (batch endpoint) sem styður allt að 30 aðgerðir í hverri beiðni.

Byggðu upp hraðatakmarkanir per leigjanda, alþjóðlega þrengingu (global throttling), veldishraða endurtilraun með tilviljun (exponential backoff with jitter), virðingu fyrir Retry-After, takmarkaða samtímavinnslu (bounded concurrency), síðunarskiptingu (pagination) og mælingar á 429 villum og eftirstandandi kvóta. Ekki nota ótakmarkaða samhliðavinnslu fyrir innflutning; einn stór viðskiptavinur getur svelt öll önnur verk á þeim leigjanda.

Festu eða stjórnaðu API-útgáfum með skýrum hætti. QuickBooks Online sjálfgefur í undirútgáfu 75 þegar engin er tilgreind. Samræmdu útgáfur í stillingum, keyrðu samningsprófanir (contract tests) gegn sandkössum (sandboxes), fylgdu útgáfutilkynningum og meðhöndlaðu óþekkta svörunarreiti sem framtíðarsamhæfða (forward-compatible). Sandkassar endurskapa ekki öll framleiðsluskilyrði, svo prófaðu aftengingu, endurtengingu, afturkölluð samþykki, útrunna lykla, hraðatakmarkanir og breytingar sem gerðar eru hjá veitu áður en farið er í loftið.

Hvað ég myndi byggja fyrst

Ef ég væri að byrja á þessu á morgun, í þessari röð:

Skilgreina nákvæmlega bókhaldsverkflæðið: hvaða atburði og hluti þú lesir eða skrifar.
Velja stefnu varðandi veitur: beint, sameinað, innbyggt eða blandað.
Smíða tengilíkön sem eru afmörkuð við leigjanda með auðkennum skipulagsheildar hjá veitu, heimildum, stöðu og metagögnum um lykla.
Útfæra OAuth með auðkenningarflæði með kóða, PKCE, stöðustaðfestingu, lágmarksheimildum og vistun lykla megin á netþjóni.
Smíða eitt millistykki veitu á bak við stöðugt innra viðmót.
Búa til auðkennisvörpun á óbreytanlegum auðkennum veitu.
Útfæra lestur fyrst; flytja inn tilvísunargögn áður en nokkrar skriftir eiga sér stað.
Bæta við upphafssamstillingarverki með síðunarskiptingu, hraðatakmörkum, stöðukvörðum og háðri röð.
Útfæra eina þrönga skrift (búa til reikning) aðeins eftir að vörpun viðskiptavinar, vöru, skatts og reiknings hefur verið staðfest.
Gera skriftir öruggar gegn endurtilraunum með innri auðkennum aðgerða, einstakleikatakmörkunum og athugunum á stöðu í fjarlægu kerfi.
Bæta við undirrituðum vefboðum sem staðfesta hratt og vinna úr ósamstillt.
Bæta við könnun og samhæfingu þannig að vefboð séu hröðun, en ekki einasta uppspretta sannleikans.
Prófa bilanastillingar af ásetningi.
Bæta við þjónustu- og endurskoðunartækjum sem gera bilanir skiljanlegar og lagfæranlegar.
Stækka þekju hluta smám saman.

FAQ

Á ég að nota sameinað API eða smíða bein tengistykki?

Notaðu beint tengistykki þegar ein veita drottnar yfir viðskiptavinum þínum eða hegðun sem er sértæk fyrir veituna skiptir sköpum. Skoðaðu sameinað API þegar breið þekja og hraði skipta máli umfram stjórn. Ef raunveruleg þörf þín er að reka bókhaldið sjálf/ur í stað þess að samstilla við kerfi viðskiptavinar, þá svarar hvorugt spurningunni; litiðu frekar á innbyggða höfuðbók eins og Nordlet.

Eru vefboð nægileg til að haldast í samstillingu?

Nei. Vefboð verða gerð óvirk, seinka, glatast og gagnapakkar geta verið ófullkomnir eða í rangri röð. Meðhöndlaðu þau sem breytingamerki, sæktu núverandi hlut á eftir og styððu þau með reglulegri könnun og samhæfingu.

Hvernig kem ég í veg fyrir að bilanir á endurnýjunarlyklum loki viðskiptavinum úti?

Vistaðu nýjasta endurnýjunarlykilinn á óskiptanlegan hátt við hverja endurnýjun, notaðu læsingu per tengingu, reynðu aftur ef tímabundnar bilanir verða á lyklaendapunkti og birtu skýra stöðu endurheimildar. 30 mínútna frestur Xero hjálpar, en óskiptanleg vistun er það sem bjargar því.

Get ég parað færslur saman eftir nafni eða netfangi viðskiptavinar?

Ekki sem varanlegu auðkenni. Nöfn breytast, tvritanir eiga sér stað og tveir viðskiptavinir geta deilt netfangi. Vistaðu óbreytanlegt auðkenni veitunnar og hafðu þitt eigið SaaS-auðkenni samhliða því.