Kas apibrėžia nekintamą dvigubo įrašo Didžiosios knygos (ledger) API

Prekyvietės (marketplace) Didžiosios knygos (ledger) neapibrėžia vien tai, ar ji saugo pinigų judėjimą. Dauguma sistemų tai daro. Ją apibrėžia tai, kas nutinka mokėjimo paslaugų teikėjui du kartus atsiuntus tą patį pranešimą (webhook), grąžinimui pasiekus sistemą po to, kai pardavėjui jau buvo išmokėtos lėšos, arba auditoriui paklausus, kaip pardavėjo balansas pasiekė dabartinę sumą. Šie momentai parodo, ar turite nekintamą dvigubo įrašo Didžiąją knygą (ledger), ar kintamą lauką su gražiu pavadinimu.

Prekyvietės platformai trumpas atsakymas yra toks: nekintamasis dvigubo įrašo Didžiosios knygos (ledger) API užregistruoja kiekvieną finansinę reikšmę turintį įvykį kaip subalansuotą žurnalo operaciją, įrašo ją atomiškai, niekada neperrašo ir leidžia programuojamu būdu išvesti balansus, atlikti suderinimą (reconciliation) su išorinėmis sistemomis bei eksportuoti istoriją. Viskas kita yra tik prie šio pagrindo priskirtos detalės.

Subalansuoti žurnalo įrašai, o ne einamojo balanso laukas

Aiškiausias testas yra tai, kaip API pateikia pardavėjo balansą. Jei balansas yra skaičius, kurį jūsų programa tiesiog padidina, tai nėra dvigubo įrašo Didžioji knyga (ledger). Jei balansas yra išvestinis rodinys iš įregistruotų žurnalo eilučių, tuomet jis toks gali būti.

Kiekvienoje operacijoje turi būti vienodas debetas ir kreditas. Pirkėjui sumokėjus 100 € už užsakymą, kuriam taikoma 15 € prekyvietės komisija, Didžiojoje knygoje (ledger) registruojamas lėšų gavimo sąskaitos debetas 100 €, pardavėjo mokėtinų sumų kreditas 85 € ir komisijos pajamų kreditas 15 €. Abi pusės visada susiveda į tą pačią sumą. Ši struktūrinė taisyklė aptinka didelę dalį klaidų dar prieš joms patenkant į ataskaitą.

Žurnalo operacijoje turi būti pateikiama bent jau:

• Unikalus, nekintamas operacijos ID;
• Debeto ir kredito eilutės, kurių kiekviena turi sąskaitą, sumą ir valiutą;
• Operacijos data ir įregistravimo žyma (timestamp);
• Verslo įvykio tipas (pardavimas, grąžinimas, išmokėjimas, pinigų grąžinimo ginčas / chargeback);
• Idempotentiškumo raktas;
• Pirminė nuoroda į užsakymą, mokėjimą arba paslaugų teikėjo įvykį;
• Būsena (laukianti, įregistruota, anuliuota);
• Paslauga arba prisijungimo duomenys, kurie tai sukūrė.

Pardavėjo lėšos tampa užklausa šioms eilutėms, o ne reikšme, kurią kažkas atnaujino programos kode. Tai svarbu todėl, kad tiesiogiai pakeistas balansas praranda kiekvieno judėjimo priežastį. „Nordlet“ modelis traktuoja dvigubo įrašo Didžiąją knygą (ledger) kaip autoritetingą įrašymo kelią: visi dokumentai įregistruoja subalansuotus žurnalo įrašus, o pati duomenų bazė atsisako priimti nesubalansuotus įrašus. Tai yra teisingas numatytasis nustatymas kiekvienam, integruojančiam apskaitą į prekyvietę.

Papildymo tipo įrašai (append-only) su kompensuojančiomis korekcijomis

„Nekintamas“ turėtų reikšti, kad įregistruoto žurnalo negalima redaguoti jo vietoje. Klaidos taisomos judant pirmyn, o ne ištrinant. Neteisingas komisijos įrašas gauna anuliavimą, kuris panaikina originalą, o tuomet pakoreguotą įrašą, kuriame užregistruojamas numatytas rezultatas. Abidvi pusės susiejamos su originalu, o audito istorija parodo, kas inicijavo pakeitimą ir kada.

API turi atmesti paprastus UPDATE ir DELETE veiksmus, nukreiptus į įregistruotus apskaitos įrašus. Ji gali leisti pridėti su finansais nesusijusius metaduomenis, pavyzdžiui, nuorodą į palaikymo bilietą, kol sumos, sąskaitos ir laiko žymos lieka nepaliestos.

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

• Veiklos nekintamumas (operational immutability): programos vartotojai negali keisti arba ištrinti įregistruotų eilučių.
• Audito nekintamumas (audit immutability): sistema gali įrodyti, kad istorija nepasikeitė.
• Teisinis saugojimas (legal retention): įrašai saugomi teisės aktų nustatytą laikotarpį.

Papildymo tipo (append-only) reliacinė duomenų bazė su griežtais leidimais, atsarginėmis kopijomis ir sutvarkytais anuliavimo darbo eigos procesais sukuria išties nekintamą Didžiąją knygą (ledger). Blokų grandinė (blockchain) čia nėra reikalavimas, o kalbant apie ES apskaitos duomenis, ji dažniausiai sukelia privatumo ir taisymo problemų, kurios nusveria pridedamą apsaugą nuo klastojimo.

Atomiškumas ir idempotentiškumas

Prekyvietės įvykis turi būti įregistruotas atomiškai. Arba įsipareigojamos visos žurnalo eilutės, arba nė viena. 100 € gavimo įregistravimas neįregistruojant 15 € komisijos sukuria nesubalansuotą, klaidinantį rezultatą, kurį vėliau kažkam teka narpliotis. „Nordlet“ užtikrina tai žemiau programos lygio: uždelstas duomenų bazės trigeris patikrina, ar kiekvienas įrašas susibalansuoja įsipareigojimo (commit) metu, todėl nesubalansuota operacija išvis negali būti patvirtinta.

Idempotentiškumas yra sritis, kurioje dauguma integracijų tyliai sugriūva. Mokėjimo sistemos bando pakartoti veiksmus tinklo tričių atveju, o atsiskaitymo failai paleidžiami iš naujo. Neturint tam tikram subjektui (tenant) arba paskyrai priskirto idempotentiškumo rakto, vienas pakartotas užklausos siuntimas sukuria dubliuotą apskaitą. Pakartota užklausa su tuo pačiu raktu turėtų grąžinti pradinę operaciją, o ne antrąją.

Raktas turi būti susietas su kilmės įvykiu, įvykio tipu, paslaugų teikėjo įvykio ID, juridiniu asmeniu ir užklausos duomenų (payload) maiša (hash). Jei tas pats raktas ateina su kita suma ar valiuta, API turėtų traktuoti tai kaip konfliktą ir atmesti, o ne tyliai priimti naujus duomenis. Tylus priėmimas yra tai, dėl ko audito sekos suyra. „Nordlet“ Idempotency-Key antraštė (header) veikia būtent taip: pakartojimas su tuo pačiu raktu ir duomenimis pateikia išsaugotą atsakymą, o tas pats raktas su kitais duomenimis yra atmetamas su klaidos pranešimu idempotency_key_reuse. Tai maža funkcija, turinti didžiulį poveikį suderinimui.

Kelių šalių padalinta apskaita (multi-party split accounting)

Prekyvietės užsakymas nėra vienas judėjimas. Vienas pardavimas gali paliesti pirkėjo lėšas, pardavėjo pajamas, prekyvietės komisiją, mokėjimų apdorojimo mokesčius, PVM nuo komisijos, pristatymą ir rezervus. Didžiajai knygai (ledger) reikalingos sąskaitų struktūros, kurios visa tai laiko atskirai, o nesupainioja į vieną grynąją sumą.

Yra paplitusi prielaida, kuriai verta paprieštarauti: mokėjimo paslaugų teikėjo „padalinto išmokėjimo“ (split payout) funkcija nėra tapatio prekyvietės apskaitai. Pinigų padalijimas gavėjams nukreipia pinigų srautus. Tai nesuteikia pilno, nekintamo uždirbtos komisijos, surinkto PVM, grąžintinų lėšų ar laikomų rezervų įrašo. Jums vis tiek reikalingė jūsų paties Didžioji knyga (ledger) ir jos suderinimas su paslaugų teikėju.

Prekyvietės Didžioji knyga (ledger) taip pat turėtų atskirti daugiau nei vieną pardavėjo balansą:

Balanso būsena	Ką ji reiškia
Laukianti (Pending)	Lėšos, susietos su įvykiu, bet dar nesuteikiančios teisės jas atsiimti
Prieinama (Available)	Lėšos, atitinkančios išleidimo, rezervų, grąžinimo ir ginčų taisykles
Sulaikyta / rezervuota (Held / reserved)	Sumos, sulaikytos dėl ginčų (chargeback), grąžinimų ar sukčiavimo kontrolės
Išmokėta (Paid out)	Sumos, pervestos pardavėjui
Neigiama / atgautina (Negative / recoverable)	Sumos, kurias pardavėjas skolingas po to, kai grąžinimai arba mokesčiai viršija prieinamas lėšas

Pinigų perkėlimas iš laukiančių į prieinamus pats savaime turi būti subalansuota žurnalo operacija, o ne pervardytas laukas.

Anuliavimai, grąžinimai ir neigiami balansai

Prekyvietės pinigų srautai juda abiem kryptimis, dažnai netvarkinga tvarka. Sunkūs atvejai yra grąžinimai po išmokėjimo ir ginčai, pasiekiantys sistemą po kelių savaičių. Respektabili Didžioji knyga (ledger) apibrėžia, kas nutinka, kai pardavėjo prieinamas balansas negali padengti grąžinimo: sukuriamas neigiamas balansas, suma perkeliama į pardavėjo gautinas sumas, pasinaudojama rezervu arba apribojami tolimesni išmokėjimai.

Kiekvienas iš šių įvykių turėtų nurodyti originalią operaciją ir ją išsaugoti. Didžioji knyga (ledger) įregistruoja grąžinimo apskaitinį padarinį. Ji nenusprendžia dėl prekyvietės grąžinimo politikos ar teisinės atsakomybės. Šios ribos išlaikymas padeda išvengti daugybės painių projektavimo pokalbių.

Valiutos ir tikslumas

Tarptautinėms prekyvietėms reikalingas tikslus pinigų tvarkymas. Sumoms turi būti naudojami ISO 4217 valiutų kodai ir tikslus atvaizdavimas, naudojant arba mažiausius sveikųjų skaičių vienetus (minor units), arba fiksuoto tikslumo dešimtaines eilutes, bet niekada slankiojamo kablelio skaičius (floats). Jokio tylaus apvalinimo. Vykstant konvertavimui, Didžioji knyga (ledger) turi išsaugoti pradinę sumą, valiutos keitimo kursą, kurso šaltinį, laiko žymą ir gaunamą sumą, o apvalinimo skirtumus įregistruoti tam skirtoje sąskaitoje.

Viena subalansuota operacija neturėtų maišyti valiutų be aiškaus valiutos keitimo mechanizmo. Jei ji tai padaro, jūsų ataskaitos neatitiks realybės būdu, kurį mėnesio pabaigoje bus sunku atsekti.

Suderinimas su išorinėmis sistemomis (reconciliation)

Viduje subalansuota Didžioji knyga (ledger) pati savaime nėra autoritetinga. Ji turi sutapti su išoriniu pasauliu: mokėjimo paslaugų teikėjo operacijomis, paslaugų teikėjo mokesčiais, atsiskaitymo ataskaitomis, banko išrašais, išmokėjimų failais ir ginčų ataskaitomis.

Subrendusi API palaiko importuotus išorinius įvykius ir sulyginimo būsenas, tokias kaip sulyginta, iš dalies sulyginta, nesulyginta, dubliuota, sumos neatitikimas ir reikalaujanti peržiūros. Suderinimų skirtumai turėtų sukurti aiškius išimčių įrašus arba apskaitos įrašus. Jie niekada neturėtų tyliai perrašyti Didžiosios knygos (ledger) istorijos. „Nordlet“ požiūris į banko išrašų suderinimą ir mokėjimų sulyginimą remiasi šiuo principu: importuoti išrašai ir „Stripe“ eksportai praleidžia viską, kas jau buvo importuota, mokėjimų pasiūlymai įvertinami pagal sumą, nuorodą, kontrahentą ir IBAN, vieno paspaudimo sulyginimas tvarko įprastus atvejus, o išimtys yra iškeliamos į paviršių, o ne sugeriamas.

ES ribos, kurių API turi paisyti, ir tos, kurių negali

Tai sritis, kurioje rinkodaros teiginiai linkę aplenkti realybę. Didžioji knyga (ledger) padeda įvykdyti ES prievoles, tačiau pati savaime jų neįvykdo.

PVM. Didžioji knyga (ledger) turi išsaugoti mokesčiams svarbius matmenis: jurisdikciją, tarifą, mokesčio kategoriją ir tai, kaip buvo nustatytas tarifas. Ji turėtų atskirti pardavėjo pardavimą pirkėjui nuo prekyvietės komisijos bei atskirti PVM nuo mokesčių ir sumų, kurios tik praeina pro šalį. „Nordlet“ tvarko kiekvienos šalies PVM skaičiavimus, VIES patvirtinimą ir i.SAF registro generavimą, kartu su OSS ir IOSS scenarijais, su kuriais susiduria ES prekyvietės. Traktuokite Didžiąją knygą (ledger) kaip įrodymą ir mokesčių variklį, o ne kaip mokesčių konsultaciją.

DAC7. Platformos atskaitomybės taisyklės reikalauja patikimų nuorodų tarp pardavėjo tapatybės, jurisdikcijos, operacijų sumų, mokesčių, grąžinimų ir išmokėjimų. Subalansuota Didžioji knyga (ledger) sukuria operacijos įrodymus. Ji nenustato, ar pardavėjas yra subjektas, apie kurį reikia teikti ataskaitas, ir nepakeičia KYC, klientų įtraukimo (onboarding) ar atskaitomybės darbo eigos. Laikykite operacijų apskaitą ir reguliavimo ataskaitų teikimą atskirais dalykais.

PSD2 ir lėšų apsauga. Pinigų judėjimo registravimas nėra tapatus licencijuotai mokėjimo paslaugai ar lėšų apsaugai. Didžioji knyga (ledger) turi padaryti pinigų srautus ir šalis aiškiais. Pati savaime ji negali suteikti mokėjimo paslaugų teikimo leidimo ar įrodyti, kad grynieji pinigai laikomi tam tikroje sąskaitoje. Tai išlieka jūsų reguliavimo vaidmens ir jūsų PSP klausimas.

BDAR (GDPR). Nekintamumas sukuria realią įtampą su duomenų apsaugos principais. Saugiausia architektūra piniginius faktus saugo nekintamajame branduolyje, o asmens duomenis – už jo ribų. Žurnalo eilutėse naudokite stabilius pseudoniminius pardavėjo ir pirkėjo identifikatorius. Kintamus asmens duomenis saugokite atskiroje, prieiga valdomoje sistemoje su savo saugojimo ir trynimo darbo eiga. „Nekintamas“ nėra licencija amžinai saugoti kiekvieną mokėjimo užklausos duomenų rinkinį.

Didžiosios knygos (ledger) API vertinimo kontrolinis sąrašas

Funkcijų etiketės yra pigios. Vietoj to išbandykite veikimą smėlio dėžėje (sandbox). Paleiskite šiuos scenarijus ir patikrinkite įrodymus:

• Įregistruokite 100 € užsakymą, padalintą tarp pardavėjo ir prekyvietės, ir patvirtinkite subalansuotą žurnalą su aiškiomis sąskaitomis.
• Nusiųskite tą pačią užklausą du kartus ir patvirtinkite, kad sukurta viena operacija be dublikatų.
• Pabandykite redaguoti įregistruotą įrašą ir patvirtinkite, kad jis atmestas arba apribotas tik su finansais nesusijusiais metaduomenimis.
• Pataisykite neteisingą komisiją ir patvirtinkite susietą anuliavimą bei pakoreguotą įrašą.
• Atlikite dalinį grąžinimą po išmokėjimo ir patvirtinkite sekamą grąžinimą su pardavėjo gautina suma arba neigiamu balansu, kur reikia.
• Pakartokite paslaugų teikėjo pranešimą (webhook) ir patvirtinkite dublikatų aptikimą.
• Apdorokite daugiavalietį atsiskaitymą ir patvirtinkite valiutos keitimo detales bei konvertavimo apskaitą.
• Užklauskite pardavėjo balanso laikotarpio pabaigoje ir patvirtinkite atgaminamą rezultatą su dokumentuota riba.
• Importuokite paslaugų teikėjo atsiskaitymą ir patvirtinkite sulyginimą su išimties būsena, kuri palieka istoriją nepaliestą.
• Eksportuokite mėnesio veiklą ir patvirtinkite išsamų, puslapiuojamą, pakartojamą išrašą.

Stipriausi įrodymai yra dokumentacija kartu su atgaminamu testu. Tokie žodžiai kaip „realiu laiku“, „paruoštas auditui“ ir „nekintamas“ nieko nereiškia be už jų stovinčio duomenų modelio, klaidų semantikos ir saugojimo elgsenos.

Į ką patikrintume pirmiausia

Jei rytoj prekyvietei vertintume Didžiosios knygos (ledger) API, prieš žiūrėdami į bet ką kita pradėtume nuo dviejų dalykų. Pirmiausia, įrodykite, kad pardavėjo balansas yra išvestas iš žurnalo eilučių, o ne kintamo lauko, nes nuo to priklauso viskas, kas vyksta vėliau. Antra, pakartokite tą patį pranešimą (webhook) ir patvirtinkite lygiai vieną apskaitos rezultatą. Šie du testai pasako apie pagrindinio dizaino kokybę daugiau nei bet koks funkcijų sąrašas.

Po to pirmiausia svarbūs API aspektai lėmė tai, kaip greitai jūsų komanda išleidžia produktus: tipizuoti SDK, pranešimai (webhooks) tokiems įvykiams kaip sale_invoice.paid, veikianti smėlio dėžė (sandbox) ir laikotarpių užrakinimas, skirtas apsaugoti uždarytus mėnesius. „Nordlet“ buvo sukurta aplink šį modelį, kai tos pačios funkcijos pasiekiamos per API kaip ir per programą, o tai leidžia platformai vykdyti auditui paruoštą apskaitą savo produkto viduje, vietoj to, kad būtų pridedamas trečiosios šalies atsiskaitymas. Platesnį vaizdą apie tai, kaip tokia Didžioji knyga (ledger) įsilieja į prekyvietės sistemų visumą, rasite mūsų vadove apie dvigubo įrašo Didžiosios knygos API prekyviečių apskaitai.

D.U.K.

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

Ne. Didžioji knyga (ledger) gali būti visiškai subalansuota, tačiau įregistruota ne į tų sąskaitų planą, taikant neteisingą PVM režimą arba priskiriant lėšas ne tam pardavėjui. Balansas yra struktūrinė kontrolė, kuri pagauna aritmetines klaidas ir trūkstamas operacijos puses. Jis nieko nesako apie tai, ar jūsų verslo logika teisingai atvaizdavo įvykį. Štai kodėl smėlio dėžės (sandbox) testavimas su realiais scenarijais yra svarbesnis nei vien balanso patikrinimas.

Ar mokėjimo paslaugų teikėjo Didžiosios knygos (ledger) prekyvietei pakanka?

Dažniausiai ne. PSP seka lėšas savo sistemoje, o tai naudinga judėjimui ir išmokėjimui. Jūsų prekyvietei vis tiek reikia savo įrašų komisijos pajamoms, pardavėjo įsipareigojimams, PVM nuo mokesčių, grąžinimams, rezervams, ginčams ir vadovybės ataskaitoms. Abi sistemas reikia sulyginti, o paslaugų teikėjo požiūrio traktavimas kaip jūsų apskaitos palieka spragas, kurios iškyla į paviršių audito metu.

Ar man reikia blokų grandinės (blockchain), kad Didžioji knyga (ledger) būtų nekintama?

Ne. Papildymo tipo (append-only) reliacinė saugykla su griežtais rašymo leidimais, kontroliuojamomis korekcijos darbo eigomis, audito žurnalais ir patikimomis atsarginėmis kopijomis suteikia jums veiklos ir audito nekintamumą. Blokų grandinė (blockchain) prideda paskirstytą apsaugą nuo klastojimo, bet sukelia privatumo, našumo ir taisymo sunkumų, kurie prieštarauja ES apskaitos ir BDAR reikalavimams. Daugumai prekyviečių ji išsprendžia problemą, kurios jos neturi.

Ar nekintama Didžioji knyga (ledger) gali saugoti duomenis amžinai pagal BDAR?

Apskaitos įrašų saugojimas teisiškai reikalaujamą laikotarpį yra priimtinas. Visų asmens duomenų arba mokėjimo duomenų rinkinių saugojimas neribotą laiką vien todėl, kad Didžioji knyga (ledger) yra nekintama, nėra priimtinas. Piniginius faktus ir pseudonimines nuorodas laikykite nekintamame branduolyje, o asmens duomenis – atskiroje sistemoje su tinkamu saugojimu ir trynimu. Nekintamumas taikomas finansiniam įvykiui, o ne kiekvienam su juo susijusiam duomenų elementui.