Kas yra apskaitos API? Suprantamas vadovas platformų kūrėjams

Paprastas apskaitos API apibrėžimas, kuo jis skiriasi nuo mokesčių ar mokėjimų API, ir ką vertėtų patikrinti prieš pradedant programuoti integraciją.

Apskaitos API yra sąsaja (interface), leidžianti vienai programai tvarkyti kitos programos apskaitą. Jūsų programinė įranga per HTTP išsiunčia finansinį įvykį. API paverčia šį įvykį subalansuotais dvejybiniais įrašais pagal sąskaitų planą, išsaugo juos taip, kad nebūtų galima nepastebimai pakeisti, pritaiko mokesčių taisykles ir per tą pačią sąsają grąžina ataskaitas, dokumentus bei eksporto failus.

Šis apibrėžimas pasako beveik viską. Visa kita šiame straipsnyje yra tiesiog iš to išplaukiantys dalykai.

Versija vienu sakiniu

Apskaitos API priima finansinius įvykius iš jūsų aplikacijos, paverčia kiekvieną iš jų subalansuotu žurnalo įrašu, išsaugo jį nekeičiamu (immutable) pavidalu kartu su mokestiniu vertinimu bei pagrindžiančiais įrodymais, ir per programines galines sritis (endpoints) pateikia suformuotą didžiąją knygą, dokumentus bei ataskaitas.

Jei produktas vadinamas apskaitos API, bet negeneruoja žurnalo įrašų, tai yra kažkas kito, tiesiog turinčio skambų pavadinimą. Tai nebūtinai blogai. Tiesiog tai reiškia, kad jis neatliks to darbo, kurio jūs iš jo tikitės.

Kuo apskaitos API nėra

Yra keturios gretutinių produktų kategorijos, kurias dažnai painioja su apskaitos API, ir paprastai tai nutinka vėlesnėse projekto stadijose.

Kategorija	Ką ji daro	Ko ji nedaro
Mokesčių skaičiavimo API	Grąžina teisingą operacijos mokesčio tarifą arba sumą	Netvarko jūsų apskaitos ir nesaugo sprendimą pagrindžiančių įrodymų visą privalomą saugojimo laikotarpį
Mokėjimų API	Perveda pinigus tarp šalių ir pateikia šių judėjimų ataskaitas	Neregistruoja uždirbtų komisinių, mokėtino PVM arba įsipareigojimų pardavėjui tarp pinigų gavimo ir išmokėjimo
Unifikuotas arba agregatoriaus API	Nuskaito ir įrašo duomenis į kliento jau naudojamą apskaitos programą	Neveikia kaip pagrindinė apskaitos sistema (system of record); jūsų apskaita vedama tame įrankyje, kurį klientas jau naudoja
Ataskaitų arba verslo analitikos (BI) API	Nuskaito skaičius iš esamos didžiosios knygos ir juos vizualizuoja	Nekuria įrašų, iš kurių tie skaičiai kyla

Kiekviena iš šių kategorijų turi realią praktinę naudą. Tačiau platformai, kuri pati turi veikti kaip pagrindinė apskaitos sistema, apskaitos API reikalingas kaip bazinis sluoksnis, o ne kaip jų pakaitalas.

Penki dalykai, kuriuos privalo daryti apskaitos API

1. Registruoti subalansuotus įrašus. Kiekvienas įvykis virsta debetu ir kreditu, kurių sumos sutampa. Kai pirkėjas sumoka 100 € per prekyvietę (marketplace), imanti 15 € komisinį mokestį, atliekamas toks įrašas: debetuojama tarpinė (clearing) sąskaita 100 €, kredituojama skola pardavėjui 85 € ir kredituojamos komisinių pajamos 15 €. Tai nėra tik buhalterinis formalumas. Tai struktūrinis patikrinimas, leidžiantis aptikti ištisas klases integracijos klaidų dar prieš joms patenkant į ataskaitą.

2. Saugoti istoriją. Užregistruotas įrašas nėra redaguojamas. Klaida taisoma stornuojant (reversal) įrašą ir sukuriant naują, teisingą įrašą; abu jie susiejami su pradiniu įrašu. Uždaryti mėnesiai yra užrakinami, kad į juos nebūtų galima įtraukti naujų, atgaline data pažymėtų įrašų.

3. Įvertinti mokesčius. ES prekybos atveju tai reiškia paslaugų suteikimo ar prekių tiekimo vietos (place of supply) nustatymą, atvirkštinio apmokestinimo (reverse charge) taikymą, PVM mokėtojo kodų tikrinimą oficialiame registre, o taip pat visų sprendimą pagrindžiančių įrodymų išsaugojimą kartu su operacija, o ne jų išmetimą atlikus skaičiavimą.

4. Suderinti su išoriniais pinigų srautais. Apskaita, kuri niekada nesuderinama su banko išrašu, yra tik spėlionė. API turi gebėti priimti banko išrašus ar mokėjimo paslaugų teikėjų ataskaitas ir sudengti juos su užregistruotais įrašais.

5. Eksportuoti duomenis. Ataskaitos, dokumentai ir audito failai privalo būti formuojami tokiais formatais, kokius priima buhalteris ir mokesčių inspekcija (VMI).

Produktas, atliekantis pirmuosius tris punktus, bet neatliekantis paskutiniųjų dviejų, vis tiek reikalaus, kad žmogus kas mėnesį dirbtų su skaičiuoklėmis.

Kaip iš tikrųjų atrodo API kreipinys

Techninė pusė yra paprastesnė nei pati apskaita. Nordlet API dokumentacijoje kiekviena operacija yra RPC stiliaus POST užklausa su nuspėjama struktūra:

POST /v1/{module}/{resource}/{action}
Authorization: Bearer <api key>
Idempotency-Key: <your event id>

Jūs sukuriate pardavimo sąskaitą faktūrą, tuomet ją išrašote (issue). Išrašymo momentu ir įvyksta apskaita: dokumentui suteikiamas nuoseklus, be spragų eilės numeris, užregistruojamas subalansuotas žurnalo įrašas ir kartu įrašomos PVM eilutės. Jūsų platformai niekada nereikia rankiniu būdu dėlioti debeto ir kredito.

Šiame fragmente trys detalės yra svarbesnės nei pačios galinės srities (endpoint) pavadinimas:

API rakto prieigos apimtis (scope). Raktas turi priskirtas teises, pavyzdžiui, sales:write, todėl integracija gauna tik tokią prieigą, kokia būtina.
Idempotentiškumo raktas (idempotency key). Pakartojus tą pačią užklausą su tais pačiais duomenimis (payload), grąžinamas išsaugotas atsakas, o ne sukuriama antra sąskaita faktūra. Išsiuntus tą patį raktą su kitais duomenimis, užklausa atmetama su klaida idempotency_key_reuse, užuot buvusi tyliai priimta.
Pinigai kaip tekstinės eilutės (strings). Sumos perduodamos kaip dešimtainės trupmenos teksto formatu, o ne kaip slankiojo kablelio (floating-point) skaičiai, nes naudojant pastaruosius prarandami centai, ir tai išryškėja metų pabaigoje.

Kokia jo vieta jūsų architektūroje

Jūsų aplikacija išlieka naudotojo sąsaja (front end) ir verslo įvykių šaltiniu. Apskaitos API tampa fonine pagrindine finansų apskaitos sistema. Paprastai procesas atrodo taip:

Jūsų produkte įvyksta veiksmas: užsakymas, pinigų grąžinimas, išmokėjimas ar prenumeratos atnaujinimas.
Jūsų serverinė dalis (backend) išsiunčia API užklausą su įvykio informacija ir idempotentiškumo raktu.
API užregistruoja žurnalo įrašą, pritaiko PVM ir grąžina identifikatorius, kuriuos išsaugote prie savo sistemos įrašų.
Webhook pranešimas, pavyzdžiui, sale_invoice.paid, informuoja jūsų sistemą apie būsenos pasikeitimą, todėl galite reaguoti į įvykius, užuot nuolat klausę sistemos apie pasikeitimus (polling).
Banko operacijos gaunamos per tiesioginį banko ryšį arba importuojant išrašą, tuomet jos sudengiamos su užregistruotais dokumentais.
Laikotarpio pabaigoje iš tų pačių duomenų sugeneruojamos ataskaitos bei mokesčių registrai, o uždarytas mėnuo užrakinamas.

Nė vienas iš šių punktų nereikalauja, kad žmogus atsidarytų apskaitos programą. Būtent tokia ir yra šios kategorijos produktų esmė.

Kaip tai atrodo lyginant su alternatyvomis

Sprendimas	Pradinių pastangų poreikis	Pozicija audito atveju	Prisitaiko prie operacijų kiekio augimo
Skaičiuoklės ir rankinis įvedimas	Mažiausias	Silpna; istoriją galima redaguoti	Ne
Apskaitos programa plius CSV eksportai	Mažas	Visiškai priklauso nuo darbuotojų disciplinos	Sunkiai; kažkas turi importuoti failus
Agregatoriaus API, jungiantis prie klientų programų	Vidutinis	Paveldi tai, ką daro kliento naudojamas įrankis	Taip, bet jūs niekada nevaldote pirminių apskaitos įrašų
Integruotas (embedded) apskaitos API	Vidutinis	Stipri, jei didžioji knyga nekeičiama (immutable), o laikotarpiai užrakinami	Taip
Nuosavos didžiosios knygos kūrimas	Didžiausias	Stipri, tik jei taip pat sukursite kontrolės mechanizmus	Taip, bet turėsite ją prižiūrėti amžinai

Nuosavos sistemos kūrimas kai kurioms komandoms yra pagrįstas pasirinkimas. Tai išsamiau aptariama mūsų „kurti ar pirkti“ vadove, skirtame prekyvietėms.

Ką patikrinti prieš programuojant integraciją

Ar likutis išskaičiuojamas, ar saugomas kaip reikšmė? Paklauskite, ar pardavėjo likutis yra duomenų bazės užklausa iš žurnalo eilučių, ar stulpelis, kurį kažkas atnaujina. Tik vienas iš šių būdų atlaikys auditą.
Kas nutinka pakartojus užklausą (retry)? Išsiųskite tą pačią užklausą du kartus ir suskaičiuokite įrašus.
Ar galima redaguoti užregistruotą įrašą? Atsakymas turėtų būti „ne“, ir turi būti dokumentuotas klaidų taisymo būdas.
Ar užrakintas laikotarpis išties atmeta naują įrašą? Išbandykite tai smėliadėžės (sandbox) aplinkoje. Nordlet grąžina 409 klaidą bandant užregistruoti įrašą, kurio data patenka į užrakintą laikotarpį.
Kaip reprezentuojami pinigai? Dešimtainėmis trupmenomis teksto formatu arba sveikaisiais skaičiais mažiausiais vienetais (centais). Niekada nenaudokite slankiojo kablelio (floats).
Kas matoma audito įrašuose (audit log)? Veikėjas (actor), veiksmas, objektas (entity) ir pats pakeitimas, ir jie turi būti pasiekiami per užklausas, o ne paslėpti žurnalų failuose.
Kokie yra užklausų limitai (rate limits)? Nordlet leidžia atlikti 300 užklausų per minutę vienam API raktui ir apie likusį užklausų biudžetą praneša atsako antraštėse. Koks bebūtų skaičius, turite jį žinoti dar prieš projektuodami duomenų sinchronizavimą.
Kaip ištraukti duomenis? Ataskaitos, dokumentai ir žurnalai privalo būti pasiekiami formatais, kuriuos galima perduoti buhalteriui.

Kiekvieną iš šių punktų per pusdienį galima išbandyti smėliadėžės (sandbox) įmonės aplinkoje. Tiekėjų funkcijų sąrašai nėra įrodymai; tikras įrodymas yra atkartojamas testas.

D.U.K.

Ar apskaitos API yra tas pats, kas apskaitos programa?

Tai yra ta pati apskaitos programa, tik su perkelta naudotojo sąsaja. Tradicinė apskaitos programa prie didžiosios knygos pasodina žmogų, tuo tarpu apskaitos API ten įdarbina jūsų kodą. Pamatiniai įsipareigojimai, dvejybinio įrašo struktūra ir ataskaitos išlieka tokios pačios.

Ar naudojant API man vis tiek prireiks buhalterio?

Taip. API automatizuoja įrašų fiksavimą, skaičiavimus ir ataskaitų formavimą. Tačiau jis nepriima sprendimų dėl klasifikavimo, atidėjinių sudarymo ar konkrečios sutarties traktavimo specifikos, be to, daugumoje šalių jis negali pasirašyti ar pateikti jūsų oficialių finansinių ataskaitų (statutory accounts).

Ar galiu naudoti apskaitos API nesuprasdamas dvejybinio įrašo?

Iš dalies taip. Geras API pats sukonstruoja žurnalo įrašus iš verslo dokumento, pavyzdžiui, sąskaitos faktūros. Tačiau vis tiek turite suprasti, ką reiškia konkrečios buhalterinės sąskaitos (accounts), kai nagrinėjate ataskaitą arba aiškinate likučio atsiradimo priežastis auditoriui.

Koks skirtumas tarp apskaitos API ir didžiosios knygos (ledger) API?

Didžiosios knygos (ledger) API registruoja subalansuotus judėjimus tarp sąskaitų. Apskaitos API daro tą patį, bet prideda papildomą mokestinį ir įstatyminį sluoksnį: dokumentus su teisėta numeracija, PVM taikymą, mokesčių registrus, ilgalaikio turto apskaitą, laikotarpio uždarymą bei jurisdikcijos reikalaujamas ataskaitas. Kiekvienas apskaitos API savyje turi didžiąją knygą; bet ne kiekviena didžioji knyga yra apskaitos sistema.

Kiek laiko trunka jo integravimas?

Pirmam veikiančiam procesui – sukurti klientą, išrašyti sąskaitą faktūrą, gauti mokėjimą, pamatyti žurnalo įrašą – turint griežto tipo (typed) SDK ir smėliadėžę, planuokite dienas, o ne savaites. Tačiau pilnai gamybinei (production) integracijai, apimančiai pinigų grąžinimus, klaidų taisymus, darbą su keliomis valiutomis, likučių derinimą bei laikotarpio uždarymą, prireiks gerokai daugiau laiko. Tikrasis laiko įvertinimas labai priklauso nuo to, kiek tokių scenarijų realiai generuoja jūsų produktas.