Kas apibrėžia nekintamą dvejybinio įrašo didžiosios knygos API

Prekyvietės (marketplace) didžioji knyga nėra apibrėžiama tuo, ar joje saugomi pinigų judėjimai. Tai daro dauguma sistemų. Ji apibrėžiama tuo, kas nutinka, kai mokėjimų paslaugų teikėjas du kartus atsiunčia tą patį „webhook“ pranešimą, kai pinigų grąžinimas įvyksta po to, kai pardavėjui jau buvo išmokėti pinigai, arba kai auditorius paklausia, kaip pardavėjo likutis pasiekė dabartinę sumą. Būtent tokios akimirkos atskleidžia, ar turite nekintamą dvejybinio įrašo didžiąją knygą (immutable double-entry ledger), ar tik kintamą laukelį su skambiu pavadinimu.

Kalbant apie prekyviečių platformas, trumpas atsakymas yra toks: nekintamos dvejybinio įrašo didžiosios knygos API kiekvieną finansinių pasekmių turintį įvykį registruoja kaip subalansuotą žurnalo operaciją, įrašo ją atomiškai, niekada jos neperrašo ir leidžia išvesti likučius, suderinti juos su išorinėmis sistemomis bei programiškai eksportuoti istoriją. Visa kita tėra detalės, papildančios šį pagrindą.

Subalansuoti žurnalo įrašai, o ne nuolat atnaujinamas likučio laukelis

Pats aiškiausias išbandymas yra tai, kaip API atvaizduoja pardavėjo likutį. Jei likutis yra skaičius, kurį jūsų programa tiesiogiai padidina, tai nėra dvejybinio įrašo didžioji knyga. Jei likutis yra išvestinė užregistruotų žurnalo eilučių reikšmė, tai jau gali būti didžioji knyga.

Kiekviena operacija turi turėti lygias debeto ir kredito sumas. Kai pirkėjas sumoka €100 už užsakymą, nuo kurio prekyvietė nuskaito €15 komisinį mokestį, didžiojoje knygoje registruojamas tarpinės sąskaitos (clearing account) debetas €100, pardavėjui mokėtinų sumų kreditas €85 ir komisinių pajamų kreditas €15. Abiejų pusių sumos visada turi sutapti. Ši struktūrinė taisyklė leidžia aptikti daugybę klaidų dar prieš joms patenkant į ataskaitą.

Žurnalo operacija turėtų atskleisti bent jau šiuos duomenis:

• Unikalus, nekintamas operacijos ID
• Debeto ir kredito eilutės, kurių kiekvienoje nurodyta sąskaita, suma ir valiuta
• Įsigaliojimo data ir registravimo laiko žyma
• Verslo įvykio tipas (pardavimas, grąžinimas, išmokėjimas, mokėjimo ginčijimas / chargeback)
• Idempotentiškumo raktas
• Šaltinio nuoroda į užsakymą, mokėjimą ar paslaugų teikėjo įvykį
• Būsena (laukia, užregistruota, stornuota)
• Sukūrusi paslauga ar prisijungimo duomenys

Tuomet pardavėjo turimos lėšos tampa šių eilučių užklausa, o ne reikšme, kurią kažkas atnaujino programos kode. Tai svarbu, nes tiesiogiai modifikuotas likutis praranda kiekvieno judėjimo priežastį. Nordlet modelyje dvejybinio įrašo didžioji knyga traktuojama kaip autoritetingas įrašymo kelias: kiekvienas dokumentas sukuria subalansuotus žurnalo įrašus, o pati duomenų bazė atmeta nesubalansuotus įrašus. Tai yra teisingas standartinis pasirinkimas visiems, integruojantiems buhalteriją į prekyvietę.

Papildomasis registravimas (append-only) su kompensuojamaisiais taisymais

„Nekintamas“ turėtų reikšti, kad užregistruoto žurnalo įrašo negalima tiesiogiai redaguoti. Klaidos taisomos pridedant naujus įrašus (fixed forward), o ne ištrinant senus. Neteisingas komisinių įrašas yra stornuojamas, taip anuliuojant pirminį įrašą, o tada sukuriamas pataisytas įrašas, kuriame užfiksuojamas norimas rezultatas. Abu šie įrašai susiejami su pirminiu, o audito istorija rodo, kas ir kada inicijavo pakeitimą.

API turėtų atmesti paprastas UPDATE ir DELETE komandas, nukreiptas į užregistruotus apskaitos įrašus. Gali būti leidžiama pridėti nefinansinius metaduomenis, pvz., nuorodą į klientų aptarnavimo užklausą, su sąlyga, kad sumos, sąskaitos ir laiko žymos liks nepakeistos.

Naudinga atskirti tris dalykus, kuriuos žmonės dažnai painioja:

• Operacinis nekintamumas: programos vartotojai negali keisti ar ištrinti užregistruotų eilučių.
• Audito nekintamumas: sistema gali įrodyti, kad istorija nebuvo pakeista.
• Teisinis saugojimas: įrašai saugomi tiek laiko, kiek reikalauja taikomi įstatymai.

Tik papildoma (append-only) reliacinė duomenų bazė su griežtais leidimais, atsarginėmis kopijomis ir disciplinuotais stornavimo procesais užtikrina iš tiesų nekintamą didžiąją knygą. „Blockchain“ (blokų grandinės) technologija čia nėra būtina, o tvarkant ES apskaitos duomenis ji dažniausiai sukelia privatumo ir taisymo problemų, kurios nusveria jos suteikiamą apsaugą nuo klastojimo.

Atomiškumas ir idempotentiškumas

Prekyvietės įvykis turi būti registruojamas atomiškai. Arba patvirtinamos visos žurnalo eilutės, arba nė viena. Užregistravus €100 įplauką, bet neužregistravus €15 komisinio mokesčio, gaunamas nesubalansuotas, klaidinantis rezultatas, kurį vėliau kažkam teks išnarplioti. Nordlet tai užtikrina žemesniame nei aplikacijos lygmenyje: atidėtas duomenų bazės trigeris patikrina, ar kiekvienas įrašas yra subalansuotas patvirtinimo (commit) metu, todėl nesubalansuotos operacijos išvis negali būti patvirtintos.

Idempotentiškumas yra ta vieta, kur dauguma integracijų nepastebimai sugenda. Mokėjimų sistemos kartoja užklausas sutrikus tinklui, o atsiskaitymų failai nuskaitomi pakartotinai. Be idempotentiškumo rakto, apriboto nuomininko (tenant) arba sąskaitos lygmeniu, viena pakartota užklausa sukuria dubliuotą apskaitos įrašą. Pakartotinė užklausa su tuo pačiu raktu turėtų grąžinti pradinę operaciją, o ne sukurti antrąją.

Raktas turėtų būti susietas su pirminiu įvykiu, įvykio tipu, paslaugų teikėjo įvykio ID, juridiniu asmeniu ir užklausos duomenų santrauka (hash). Jei tas pats raktas gaunamas su kita suma ar valiuta, API turėtų tai traktuoti kaip konfliktą ir atmesti, užuot tyliai priėmęs naujus duomenis. Tylus priėmimas yra tai, dėl ko genda audito sekos. Nordlet Idempotency-Key header veikia būtent taip: pakartojus užklausą su tuo pačiu raktu ir duomenimis, grąžinamas išsaugotas atsakas, o pateikus tą patį raktą su kitais duomenimis, užklausa atmetama su klaida idempotency_key_reuse. Tai nedidelė funkcija, daranti milžinišką įtaką likučių derinimui.

Kelių šalių padalintoji apskaita (split accounting)

Prekyvietės užsakymas nėra vienas pinigų judėjimas. Vienas pardavimas gali apimti pirkėjo lėšas, pardavėjo pajamas, prekyvietės komisinius, mokėjimų apdorojimo mokesčius, komisinių PVM, siuntimą ir rezervus. Didžiajai knygai reikalingos sąskaitų struktūros, kurios šiuos elementus atskirtų, o ne sujungtų į vieną grynąją sumą.

Verta paneigti vieną paplitusią prielaidą: mokėjimų teikėjo „split payout“ (padalinto išmokėjimo) funkcija nėra tas pats, kas prekyvietės apskaita. Pinigų padalinimas gavėjams tiesiog paskirsto grynųjų pinigų srautus. Tai nesuteikia išsamaus, nekintamo uždirbtų komisinių, surinkto PVM, mokėtinų grąžinimų ar sulaikytų rezervų įrašo. Jums vis tiek reikia nuosavos didžiosios knygos ir vis tiek turite ją suderinti su mokėjimų paslaugų teikėjo duomenimis.

Prekyvietės didžioji knyga taip pat turėtų išskirti daugiau nei vieną pardavėjo likutį:

Likučio būsena	Ką ji reiškia
Laukia (Pending)	Lėšos, susietos su įvykiu, bet dar netinkamos išėmimui
Prieinamas (Available)	Lėšos, atitinkančios išleidimo, rezervų, grąžinimų ir ginčų taisykles
Sulaikytas / rezervuotas (Held / reserved)	Sumos, sulaikytos dėl mokėjimų ginčijimų, grąžinimų ar sukčiavimo kontrolės
Išmokėtas (Paid out)	Sumos, pervestos pardavėjui
Neigiamas / išieškotinas (Negative / recoverable)	Sumos, kurias pardavėjas skolingas po to, kai grąžinimai ar mokesčiai viršijo turimas lėšas

Pinigų perkėlimas iš laukiančio į prieinamą likutį pats savaime turi būti subalansuota žurnalo operacija, o ne tiesiog pervadintas laukelis.

Stornavimai, pinigų grąžinimai ir neigiami likučiai

Pinigų srautai prekyvietėje juda abiem kryptimis ir dažnai ne iš eilės. Sudėtingiausi atvejai yra pinigų grąžinimas po lėšų išmokėjimo ir mokėjimų ginčijimai (chargebacks), atkeliaujantys po kelių savaičių. Rimta didžioji knyga apibrėžia, kas nutinka, kai pardavėjo turimas likutis negali padengti grąžinimo: sukuriamas neigiamas likutis, suma perkeliama į pardavėjo gautinas sumas, panaudojamas rezervas arba apribojami tolesni išmokėjimai.

Kiekvienas iš šių įvykių turėtų turėti nuorodą į pirminę operaciją ir ją išsaugoti. Didžiojoje knygoje registruojamos buhalterinės pinigų grąžinimo pasekmės. Ji nesprendžia prekyvietės pinigų grąžinimo politikos ar teisinės atsakomybės. Aiškus šios ribos išlaikymas padeda išvengti daugybės painių diskusijų apie sistemos dizainą.

Valiutos ir tikslumas

Tarptautinėms prekyvietėms reikalingas tikslus pinigų tvarkymas. Sumoms turi būti naudojami ISO 4217 valiutų kodai ir tikslus atvaizdavimas – arba sveikieji skaičiai smulkiausiais vienetais, arba fiksuoto tikslumo dešimtainių skaičių eilutės, bet jokiu būdu ne slankiojo kablelio skaičiai. Jokių tylių apvalinimų. Vykstant konvertavimui, didžiojoje knygoje turi būti išsaugota pradinė suma, valiutos keitimo kursas, kurso šaltinis, laiko žyma ir gautoji suma, o apvalinimo skirtumai registruojami tam skirtoje sąskaitoje.

Viena subalansuota operacija neturėtų maišyti valiutų be aiškaus valiutos keitimo (FX) mechanizmo. Priešingu atveju jūsų ataskaitos neatitiks realybės taip, kad mėnesio pabaigoje bus labai sunku atsekti klaidas.

Derinimas su išorinėmis sistemomis

Vidiniai subalansuota didžioji knyga pati savaime nėra autoritetinga. Ji turi sutapti su išoriniu pasauliu: mokėjimų paslaugų teikėjo operacijomis, teikėjo mokesčiais, atsiskaitymų ataskaitomis, banko išrašais, išmokėjimų failais ir mokėjimų ginčijimo ataskaitomis.

Brandus API palaiko importuotus išorinius įvykius ir derinimo būsenas, tokias kaip: suderinta, dalinai suderinta, nesuderinta, dublikatas, sumos nesutapimas ir reikalauja peržiūros. Derinimo skirtumai turėtų sukurti aiškius išimčių įrašus arba buhalterinius įrašus. Jie niekada neturėtų tyliai perrašyti didžiosios knygos istorijos. Nordlet požiūris į bankų likučių derinimą ir mokėjimų sutapatinimą remiasi šiuo principu: importuoti išrašai ir Stripe eksportai praleidžia tai, kas jau importuota; mokėjimų pasiūlymai vertinami pagal sumą, nuorodą, kontrahentą ir IBAN; vieno paspaudimo derinimas susidoroja su įprastais atvejais, o išimtys yra iškeliamos į paviršių, užuot jas tyliai priėmus.

ES ribos, kurių API turėtų laikytis, ir tos, kurių negali

Būtent čia rinkodaros pareiškimai dažniausiai prasilenkia su realybe. Didžioji knyga padeda vykdyti ES prievoles, tačiau pati savaime jų neužtikrina.

PVM. Didžioji knyga turėtų išsaugoti mokesčiams svarbius aspektus: jurisdikciją, tarifą, mokesčių kategoriją ir tai, kaip tarifas buvo nustatytas. Ji turėtų atskirti pardavėjo pardavimą pirkėjui nuo prekyvietės komisinių, ir atskirti PVM, taikomą mokesčiams, nuo tiesiog tranzitu praeinančių sumų. Nordlet apdoroja kiekvienos šalies PVM skaičiavimus, VIES validavimą ir i.SAF registrų generavimą, kartu su OSS ir IOSS scenarijais, su kuriais susiduria ES prekyvietės. Traktuokite didžiąją knygą kaip įrodymus ir mokesčių variklį, o ne kaip mokesčių konsultaciją.

DAC7. Platformų ataskaitų teikimo taisyklės reikalauja patikimų sąsajų tarp pardavėjo tapatybės, jurisdikcijos, bendrųjų operacijų sumų, mokesčių, grąžinimų ir išmokėjimų. Subalansuota didžioji knyga pateikia operacijų įrodymus. Ji nenustato, ar apie pardavėją privaloma teikti ataskaitas, ir nepakeičia KYC, klientų įtraukimo ar ataskaitų teikimo proceso. Operacijų apskaitą ir reguliavimo ataskaitas traktuokite kaip atskirus procesus.

PSD2 ir lėšų saugojimas. Pinigų judėjimo fiksavimas nėra tas pats, kas licencijuotos mokėjimo paslaugos teikimas ar lėšų apsauga. Didžioji knyga turi aiškiai parodyti lėšų srautus ir dalyvaujančias šalis. Ji pati negali suteikti mokėjimo paslaugų autorizacijos arba įrodyti, kad grynieji pinigai laikomi konkrečioje sąskaitoje. Tai išlieka jūsų reguliacinio vaidmens ir jūsų PSP klausimu.

GDPR. Nekintamumas sukuria realią įtampą su duomenų apsaugos principais. Saugiausia architektūra piniginius faktus laiko nekintamame branduolyje, o asmens duomenis – už jo ribų. Žurnalo eilutėse naudokite stabilias pseudonimines pardavėjų ir klientų nuorodas. Kintamus asmens duomenis saugokite atskiroje sistemoje su kontroliuojama prieiga, kurioje veiktų atskiras saugojimo ir trynimo procesas. „Nekintamas“ nėra leidimas visam laikui išsaugoti kiekvieno mokėjimo duomenis.

Kontrolinis sąrašas vertinant didžiosios knygos API

Funkcijų pavadinimai yra nieko verti. Geriau išbandykite veikimą bandomojoje aplinkoje (sandbox). Paleiskite šiuos scenarijus ir patikrinkite įrodymus:

• Užregistruokite €100 užsakymą, padalintą tarp pardavėjo ir prekyvietės, ir patvirtinkite, kad žurnalas yra subalansuotas su aiškiai nurodytomis sąskaitomis.
• Išsiųskite tą pačią užklausą du kartus ir patvirtinkite, kad sukurta viena operacija, be dublikatų.
• Pabandykite redaguoti užregistruotą įrašą ir patvirtinkite, kad veiksmas atmestas arba apsiriboja tik nefinansiniais metaduomenimis.
• Ištaisykite neteisingą komisinį mokestį ir patvirtinkite susietą stornavimo bei pataisytą įrašą.
• Atlikite dalinį pinigų grąžinimą po lėšų išmokėjimo ir patvirtinkite, kad atsekamas grąžinimas sukūrė pardavėjo gautiną sumą arba neigiamą likutį, ten, kur reikia.
• Pakartotinai paleiskite paslaugų teikėjo „webhook“ ir patvirtinkite, kad dublikatas buvo aptiktas.
• Apdorokite kelių valiutų atsiskaitymą ir patvirtinkite FX detales bei konversijos apskaitą.
• Užklauskite pardavėjo likutį laikotarpio pabaigoje ir patvirtinkite atkuriamą rezultatą su dokumentuotu atskyrimo laiku.
• Importuokite paslaugų teikėjo atsiskaitymą ir patvirtinkite sutapatinimą su išimties būsena, paliekant istoriją nepaliestą.
• Eksportuokite mėnesio veiklą ir patvirtinkite išsamų, puslapiuotą bei pakartojamą išrašą.

Stipriausias įrodymas yra dokumentacija kartu su atkuriamu testu. Tokie žodžiai kaip „realiu laiku“, „paruoštas auditui“ ir „nekintamas“ nereiškia nieko, jei už jų neslypi tinkamas duomenų modelis, klaidų semantika ir duomenų saugojimo logika.

Ką mes patikrintume pirmiausiai

Jei rytoj vertintume prekyvietei skirtą didžiosios knygos API, prieš nagrinėdami bet ką kitą pradėtume nuo dviejų dalykų. Pirma, įrodykite, kad pardavėjo likutis išvedamas iš žurnalo eilučių, o ne iš kintamo laukelio, nes nuo to priklauso visi tolesni procesai. Antra, pakartotinai paleiskite tą patį „webhook“ ir patvirtinkite, kad gaunamas lygiai vienas buhalterinis rezultatas. Šie du testai pasako daugiau apie pamatinių architektūros sprendimų kokybę nei bet koks funkcijų sąrašas.

Po to API dizaino (API-first) sprendimai nulems tai, kaip greitai jūsų komanda diegia naujoves: tipizuoti SDK, webhook pranešimai tokiems įvykiams kaip sale_invoice.paid, veikianti bandomoji aplinka ir laikotarpio užrakinimas siekiant apsaugoti uždarytus mėnesius. Nordlet buvo sukurtas remiantis šiuo modeliu, turintis tą patį funkcijų rinkinį prieinamą per API kaip ir per pačią programėlę. Būtent tai leidžia platformai vesti auditui paruoštą apskaitą savo nuosavame produkte, užuot „prisukus“ trečiosios šalies atsiskaitymo sprendimą. Norėdami sužinoti daugiau, kaip tokia didžioji knyga įsilieja į prekyvietės technologijų steką, skaitykite mūsų vadovą apie dvejybinio įrašo didžiosios knygos API prekyviečių apskaitai.

D.U.K.

Ar dvejybinis įrašas garantuoja, kad mano apskaita yra teisinga?

Ne. Didžioji knyga gali būti idealiai subalansuota, net jei sumos registruojamos neteisingose sąskaitose, taikomas klaidingas PVM režimas ar lėšos priskiriamos neteisingam pardavėjui. Balansas tėra struktūrinė kontrolė, padedanti aptikti aritmetines klaidas ir trūkstamas operacijos puses. Jis nieko nesako apie tai, ar jūsų verslo logika teisingai susiejo įvykį. Štai kodėl testavimas bandomojoje aplinkoje naudojant realius scenarijus yra svarbesnis nei vien tik balanso patikrinimas.

Ar prekyvietei pakanka mokėjimų paslaugų teikėjo didžiosios knygos?

Dažniausiai ne. Mokėjimo paslaugų teikėjas stebi lėšas savo sistemoje, o tai naudinga pervedimams ir išmokėjimams. Jūsų prekyvietei vis tiek reikia nuosavų įrašų apie komisinių pajamas, pardavėjo įsipareigojimus, mokesčiams taikomą PVM, grąžinimus, rezervus, ginčus ir valdymo ataskaitas. Šios dvi sistemos turi būti derinamos, o paslaugų teikėjo rodmenų traktavimas kaip jūsų apskaitos palieka spragas, kurios iškyla į paviršių audito metu.

Ar man reikia „blockchain“ (blokų grandinės), kad didžioji knyga taptų nekintama?

Ne. Papildoma (append-only) reliacinė duomenų bazė su griežtais įrašymo leidimais, kontroliuojamais taisymo procesais, audito žurnalais ir patikimomis atsarginėmis kopijomis suteikia operacinį bei audito nekintamumą. „Blockchain“ prideda paskirstytus įrodymus nuo klastojimo, tačiau atneša privatumo, našumo ir taisymo sunkumų, kurie prieštarauja ES apskaitos ir BDAR reikalavimams. Daugumai prekyviečių ji sprendžia problemą, kurios jos neturi.

Ar pagal BDAR nekintama didžioji knyga gali saugoti duomenis amžinai?

Apskaitos įrašų saugojimas įstatymų reikalaujamą laikotarpį yra priimtinas. Pilnų asmens duomenų ar visų mokėjimo užklausų duomenų saugojimas neribotą laiką tik todėl, kad didžioji knyga yra nekintama – nėra priimtinas. Piniginius faktus ir pseudonimines nuorodas laikykite nekintamame branduolyje, o asmens duomenis saugokite atskiroje sistemoje su tinkama saugojimo ir trynimo tvarka. Nekintamumas taikomas finansiniam įvykiui, o ne kiekvienam prie jo pridėtam duomenų vienetui.