Plan testiranja računovodstvenog API-ja prije produkcije

Odgovor 201 Created s računovodstvenog API-ja ne govori vam gotovo ništa. On potvrđuje da je poslužitelj odgovorio. Ne potvrđuje da postoji točno jedna faktura, da dugovna strana jednak potražnoj, da je broj dokumenta dodijeljen jednom ili da ponovni pokušaj nakon puknute veze neće proknjižiti i drugu kopiju. Većina produkcijskih računovodstvenih dvostrukih unosa dolazi upravo iz tog jaz: mutacije koja je izvršena na poslužitelju dok je klijent čekao s nepoznatim ishodom i tiho ponovio zahtjev s novim ključem.

Ovaj je plan namijenjen timovima koji procjenjuju računovodstveni API prije nego što ga povežu sa stvarnim knjigama. Fokusira se na ponašanje u slučaju greške, a ne na idealne scenarije (happy paths). Svako područje u nastavku navodi što treba testirati, što treba provjeriti (assert) i što se smatra prolazom. Kontekst implementacije ovdje je Nordlet, čiji API koristi bearer ključeve s određenim opsegom (scoped bearer keys), decimalne iznose u obliku tekstualnih nizova, ključeve idempotencije (idempotency keys) i potpisane webhooks. Točnu sintaksu krajnjih točaka (endpoints) i ugovore o odgovorima potražite na stranicama Konvencije za API i Početak rada umjesto da se oslanjate na pretpostavke.

Što "prolaz" zapravo znači

Test dokazuje da je računovodstvena integracija sigurna samo onda kada provjerava semantiku, a ne kodove statusa. Za svaki scenarij, paket testova trebao bi potvrditi:

• Poslovnu nuspojavu: postoji točno jedan kupac, faktura, stavka dnevnika, dodijeljeni broj ili prijelaz plaćanja.
• Računovodstveni integritet: dugovna strana jednaka je potražnoj, a novčana preciznost preživljava serijalizaciju.
• Ponašanje kod ponavljanja: ponovljeni pokušaj vraća izvorni rezultat umjesto novog zapisa.
• Trajnost: zapisi revizije i webhook događaji postoje nakon što se operacija izvrši.
• Neuspjehe bez nuspojava: odbijeni zahtjevi ne troše brojeve dokumenata niti upisuju djelomične retke glavne knjige.
• Oporavak: privremena pogreška može se ponoviti bez stvaranja duplikata ili trajnog gubitka.

Googleove smjernice za API jasno povlače crtu: samo su one operacije čije ponovljeno izvršavanje ostavlja isto konačno stanje sigurne za ponovno pokretanje, a API bi trebao identificirati koje su operacije idempotentne umjesto da naslijepo ponavlja svaku pogrešku.

Postavljanje jednokratnog, promatranog okruženja

Koristite probnu (sandbox) tvrtku, a ne produkcijske knjige. Nordletova sandbox tvrtka koristi iste module i ponašanje API-ja kao stvarna tvrtka i označena je kao testni podatak, što je čini sigurnom za testove velikog obujma s duplikatima i pogreškama. Ta se oznaka ne može mijenjati nakon stvaranja, tako da se stvarne knjige kasnije ne mogu ponovno klasificirati kao testni podaci. Imajte na umu da se korištenje sandbox okruženja mjeri i naplaćuje potpuno isto kao i korištenje u stvarnoj tvrtki, stoga prilagodite obujam svojih testova opterećenja cjeniku na kojem se nalazite.

Prije pisanja bilo kojeg testa pripremite:

• Namjensku sandbox tvrtku s postavkom isSandbox: true.
• Testni API ključ čiji je opseg ograničen samo na module koji se testiraju.
• Webhook krajnju točku ili lokalni tunel koji čuva izvorno tijelo zahtjeva.
• Unaprijed unesene kupce, dobavljače i poznati kontni plan.
• Najmanje dva računovodstvena razdoblja: jedno otvoreno, jedno zaključano.
• Testni sat ili fiksni datum ako implementacija to podržava.
• Lokalnu pohranu koja bilježi svaki pokušaj zahtjeva, ključ idempotencije, hash odgovora, isporuku webhooka i rezultat usklađivanja (reconciliation).

Nemojte pokretati testove duplikata na dijeljenim pripremnim (staging) podacima. Zalutali kupac ili faktura iz ranijeg pokretanja čini naknadne provjere dvosmislenima.

Vaš predložak za svaku mutaciju trebao bi bilježiti metodu, krajnju točku, puno tijelo (body), ključ idempotencije, opseg ključa, klijentski ID korelaciju, vremenske oznake početka i završetka, status odgovora, zaglavlja, tijelo, ID zahtjeva i podatak je li veza pukla prije nego što je odgovor stigao. Koristite fiksne decimalne nizove poput "75.0000" za novčane iznose. Nordlet prikazuje novčane vrijednosti kao decimalne nizove s do četiri decimalna mjesta, a njegov primjer fakture koristi upravo taj oblik.

Druga polovina pripreme je ubrizgavanje pogrešaka (failure injection). Vaš bi alat trebao moći odgoditi odgovor, prekinuti TCP vezu nakon što je poslužitelj primio zahtjev, vratiti sintetičke odgovore 429/500/502/503/504, vratiti neuspješan odgovor (non-2xx) s primatelja webhooka, isporučiti isti webhook dva puta, promijeniti redoslijed događaja, oštetiti jedan bajt tijela webhooka, promijeniti podatke ključa idempotencije uz zadržavanje istog ključa, pokrenuti dva identična zahtjeva istovremeno te zaključati razdoblje između postavljanja i knjiženja. Ovi scenariji vrijede više od stotinu primjera s idealnim scenarijima.

Zaključajte ugovor (contract) prije pisanja logike za ponovite pokušaje

Generirajte ili dohvatite OpenAPI shemu i usporedite je sa svojim klijentom. Nordlet objavljuje svoju OpenAPI specifikaciju u API referenci i generira svoje tipizirane SDK-ove iz iste te specifikacije, stoga testovi temeljeni na shemi nadmašuju ručno pisana nagađanja.

Provjerite obavezne polja i tipove, polja decimalnih nizova, formate datuma i vremenskih oznaka, dopuštene radnje i opsege, oblik obavijesti o pogrešci, sheme webhook događaja, koje mutacije prihvaćaju ključ idempotencije te koja polja odgovora identificiraju kreirani objekt.

Kriteriji prolaza. Klijent lokalno odbija nevažeće podatke tamo ih shema dopušta. Odgovori poslužitelja odgovaraju dokumentiranoj shemi. Nevažeće decimale, loši datumi i nedostajuća obavezna polja proizvode strukturirane pogreške provjere valjanosti. Za determinističku pogrešku provjere valjanosti ne pokušava se ponovni unos.

Način kvara koji treba otkriti. Klijent pretvara "121.0000" u binarni decimalni broj s pomičnim zarezom (float) i kasnije serijalizira malo drugačiji iznos. Cijeli brojevi prolaze; stavke PDV-a i razlomljene količine ne uspijevaju. Testirajte novčane iznose kao nizove od početka do kraja.

Autorizacija i izolacija stanara (tenants)

Koristite odvojene ključeve za čitanje i pisanje. Zatim testirajte cijelu matricu: nedostajući ključ, nevažeći ključ, važeći ključ s nedovoljnim opsegom modula, važeći ključ s ispravnim opsegom, ključ koji pripada drugoj tvrtki i pokušaj čitanja objekta iz druge tvrtke.

Provjere:

• Nedostajući ili nevažeći vjerodajnice vraćaju 401.
• Važeći ključ bez potrebne dozvole vraća 403.
• Ni za jednu pogrešku ne stvara se računovodstvena nuspojava.
• Uspješan zahtjev ne može čitati ili mijenjati zapise druge tvrtke.
• Sigurnosne pogreške se nikada ne ponavljaju automatski.

Kriterij prolaza. Možete dokazati ispravnost autorizacije i izolaciju stanara naknadnim čitanjem nakon testa, a ne samo kodovima statusa.

Dokažite jednu čistu transakciju

Pokrenite mali, deterministički tijek: kreirajte ili pronađite testnog kupca, kreirajte fakturu s decimalnim iznosima u obliku tekstualnih nizova, izdajte je, pročitajte fakturu i njezin računovodstveni učinak, pročitajte zapis revizije i primite webhook. Nordletov primjer za početak rada (Getting Started) prikazuje izdavanje fakture koje dodjeljuje broj bez rupa, provjerava je li razdoblje otvoreno i knjiži uravnoteženu stavku dnevnika u istoj transakciji.

Potvrdite da faktura doseže očekivano stanje, da je broj dokumenta dodijeljen točno jednom, da su dugovna i potražna strana jednake, da PDV i ukupni iznosi stavki odgovaraju očekivanom zaokruživanju na višu vrijednost (half-up calculation), da zapis revizije navodi sudionika i promjenu, da je webhook na kraju isporučen te da se odgovor API-ja i naknadno čitanje slažu oko ID-a fakture i stanja.

Jedna razlika koju vrijedi zapamtiti: dolazak webhooka nije dokaz da je mutacija izvršena. Odgovor API-ja plus ponovno čitanje vaše su primarne transakcijske provjere. Webhook dokazuje naknadnu obavijest i testira se zasebno.

Idempotencija: isti ključ, isto tijelo

Generirajte jedan ključ po logičnoj poslovnoj operaciji, a ne jedan ključ po mrežnom pokušaju. Pošaljite mutaciju s ključem K i tijelom B, spremite kreirani ID, a zatim pošaljite potpuno isti zahtjev ponovno.

Potvrdite da drugi odgovor predstavlja istu operaciju, da je ID objekta identičan te da postoji jedan poslovni objekt, jedan knjižni unos, jedan broj dokumenta i jedan financijski učinak. Ponovljeni odgovor trebao bi nositi dokumentirano zaglavlje ponavljanja - u Nordletovom slučaju x-idempotent-replay: true - a trag revizije ne smije pokazivati drugu mutaciju.

Dva pravila pohrane mijenjaju ono što vaš krug ponovljenih pokušaja treba očekivati, stoga ih testirajte izravno: spremljeni 4xx ponavlja se kao i svaki drugi odgovor, dok se 5xx uopće ne sprema, pa ponovljeni pokušaj nakon pogreške poslužitelja ponovno izvršava operaciju umjesto da ponavlja odgovor. Ključevi također ističu, u Nordletu nakon 24 sata, što ograničava koliko dugo je ponavljanje dostupno.

Nordletova dokumentacija obećava da dodavanje zaglavlja Idempotency-Key sprječava ponovljeni zahtjev u stvaranju duplikata, a njegove API konvencije definiraju točno zaglavlje ponavljanja i zahtjev da odgovor bude identičan u bajt. Princip odgovara Stripeovom objavljenom modelu: ključ identificira logičnu operaciju, ponavljanja vraćaju spremljeni rezultat, a ključ koji se ponovno koristi s različitim parametrima se odbija umjesto da se tiho mijenja.

Kriterij prolaza. Postoji točno jedan prijelaz financijskog stanja bez obzira na to koliko puta klijent pošalje isti zahtjev unutar prozora za ponavljanje.

Idempotencija: isti ključ, promijenjeno tijelo

Pošaljite izvorni zahtjev s ključem K i tijelom B1, a zatim drugi zahtjev s ključem K i tijelom B2 gdje se razlikuje barem jedan iznos, kupac, datum ili stavka.

Očekivani rezultat: zahtjev se odbija s dokumentiranom pogreškom ponovne upotrebe ključa - Nordlet vraća 422 idempotency_key_reuse - izvorni zapis ostaje netaknut, ne pojavljuje se drugi zapis, broj ili mutacija revizije, a klijent to ne "ispravlja" generiranjem novog ključa. Tiho prihvaćanje B2 učinilo bi ključeve za ponavljanje nesigurnima.

Istovremeni dvostruki zahtjevi

Pošaljite dva identična zahtjeva s istim ključem u isto vrijeme. Ovisno o dokumentiranom ponašanju, jedan se izvršava dok drugi prima sukob zbog rada u tijeku - Nordlet vraća 409 idempotency_in_progress - ili oba na kraju vide isti rezultat.

Potvrdite da oba poziva ne mogu stvoriti neovisne financijske učinke, da se dodjeljuje najviše jedan broj dokumenta, da se privremeni sukob ponavlja s istim ključem umjesto s novim, da je konačni resurs potpun i čitljiv te da zapis idempotencije ne ostaje trajno zaglavljen.

Način kvara. Biblioteka za ponavljanje koja stvara svježi UUID pri svakom pokušaju pretvara jednu logičnu operaciju u nekoliko neovisnih upisa i potpuno uništava idempotenciju.

Nesiguran ishod nakon puknute veze

Ovo je pojedinačno najvažnija produkcijska simulacija. Pošaljite mutaciju s ključem K, dopustite poslužitelju da je izvrši, prekinite vezu prije nego što odgovor stigne, zabilježite ishod kao nepoznat, a zatim pokušajte ponovno s istim ključem K i uskladite stanje čitanjem resursa i podataka revizije.

Potvrdite da ponovljeni pokušaj vraća izvorni ili dokumentirani ponovljeni odgovor, da postoji točno jedna financijska nuspojava, da klijent označava operaciju dovršenom tek nakon uspješnog ponavljanja ili čitanja usklađivanja te da se ne generira novi ključ. Vremenski rok (timeout) ne znači "ništa se nije dogodilo." Stripe opisuje idempotenciju upravo kao zaštitu od pogrešaka u vezi gdje je poslužitelj možda obradio mutaciju prije nego što je klijent uspio primiti odgovor.

Konzervativna politika ponavljanja

Odluke o ponavljanju ovise o pogrešci i o tome je li operacija idempotentna, a ne samo o HTTP metodi.

Obično se može ponoviti, zadržan isti ključ: ponovno postavljanje veze ili istek vremena (timeout) nakon idempotentne mutacije, 408, 429 nakon uvažavanja zaglavlja retry-after te 502/503/504. Dokumentirani odgovor idempotencije u tijeku može se ponoviti nakon kratke odgode.

Ne može se ponoviti bez usklađivanja: 400/422 pogreške provjere valjanosti, 401/403 pogreške autorizacije, 404 za nedostajući resurs, poslovni 409 sukobi koji nisu povezani s ključem u tijeku, promijenjeni podaci na postojećem ključu i odbijanje zbog zaključanog razdoblja.

Potvrdite ograničeno eksponencijalno usporavanje s nasumičnim odstupanjem (jitter), izričit maksimalni broj pokušaja i proteklo vrijeme, uvažavanje retry-after zaglavlja za ograničenja brzine (rate limits), zadržavanje istog ključa tijekom ponavljanja jedne operacije, novi ključ za svaku novu operaciju te zapisnike (logs) koji odvajaju izvorni pokušaj od ponovljenih.

Testirajte ograničavanje brzine zasebno. Prijeđite dokumentirani prag - Nordlet prema zadanim postavkama dopušta 300 zahtjeva u minuti po API ključu, a neke neautentificirane krajnje točke nose vlastita niža ograničenja po adresi - a zatim potvrdite da poslužitelj vraća odgovor o ograničenju brzine, da klijent retry-after tumači kao odgodu umjesto kao pogrešku, da pauzira umjesto da nastavi s opterećenjem te da ponovljeni pokušaj prigušene mutacije ponovno koristi izvorni ključ. Zaglavlja x-ratelimit-* izvještavaju o preostalom budžetu, što predstavlja dobru pretprovjeru. Držite testove ograničenja brzine podalje od financijskih provjera osim ako vaš predložak može razlikovati prigušeni pokušaj od onog koji je izvršen.

Provjera potpisa webhooka

Izgradite primatelj koji čuva izvorne bajtove. Za svaki događaj: uhvatite izvorno tijelo, pročitajte zaglavlje x-nordlet-signature, izračunajte očekivani HMAC-SHA256 s tajnim ključem pretplate, usporedite koristeći funkciju otpornu na vremenske napade (constant-time function), parsirajte JSON tek nakon provjere, zabilježite isporuku i vratite brzi 2xx odgovor nakon trajnog prihvaćanja. Nordlet potpisuje HMAC preko izvornog tijela, šalje ga kao sha256=<hex> i ponavlja isporuke s eksponencijalnim usporavanjem. Stripeove smjernice za webhooks naglašavaju provjeru neizmijenjenog izvornog tijela usporedbom otpornom na vremenske napade.

Pokrenite negativne testove: ispravno tijelo i tajni ključ, ispravno tijelo s krivim tajnim ključem, promjena jednog bajta u tijelu, ponovno serijalizirani JSON s izmijenjenim razmacima, nedostajuće zaglavlje, neispravan potpis, ponovljena stara isporuka ako shema uključuje vremensku oznaku te valjani potpis isporučen na krivu pretplatu.

Kriteriji prolaza. Prihvaćaju se samo ispravno izvorno tijelo i tajni ključ. Nevažeći potpisi dobivaju odgovor koji nije 2xx. Nevažeći podaci nikada ne ulaze u računovodstveni red čekanja. Tajni ključevi ostaju izvan uobičajenih zapisnika. Primatelj potvrđuje prijam tek nakon što je događaj trajno zabilježen.

Dvostruki i neuredni (out-of-order) webhooks

Pouzdanost isporuke zaseban je problem od idempotencije API-ja, stoga i primatelj mora biti idempotentni. Isporucite isti događaj dva puta, isporučite događaj sale_invoice.paid prije događaja sale_invoice.issued, vratite 500 nakon trajnog spremanja, ali prije odgovora, i ponovite događaj koji je potrošač već obradio.

Potvrdite da dvostruke isporuke ne dupliciraju plaćanja, promjene statusa ili radnje dnevnika, da ključ za uklanjanje duplikata koristi ID isporuke ili događaja pružatelja usluge kada postoji (ili dokumentirani složeni ključ, nikada proizvoljnu vremensku oznaku), da događaji izvan redoslijeda nikada ne prepisuju novije stanje starijim, da potrošač može dohvatit trenutačno stanje s API-ja kada redoslijed nije dovoljan te da neuspjeli pokušaji potrošača prolaze kroz red čekanja ili putanju za mrtve poruke (dead-letter path). Stripe izričito upozorava da redoslijed isporuke nije zajamčen i preporučuje spremanje obrađenih ID-ova događaja.

Neka krajnja točka ostane jednostavna: provjerite oblik, provjerite potpis, spremite ili stavite u red čekanja, potvrdite i vratite 2xx. Usklađivanje i obavijesti spadaju u asinkronu obradu. Testirajte to tako da natjerate radnju na nižoj razini da pričeka duže od vremena predviđenog za istek (timeout) isporuke; ispravan primatelj i dalje potvrđuje prijam nakon trajnog stavljanja u red čekanja.

Otvorena i zaključana računovodstvena razdoblja

Nordlet provodi zaključavanje razdoblja u trenutku knjiženja kroz ručne dnevnike, tijekove dokumenata i uvoze, stoga testirajte ovu kontrolu na više od jednog mjesta. Kreirajte ekvivalentne dokumente datirane u otvoreno razdoblje, u zaključano razdoblje, na granicu neposredno prije zaključavanja, na prvi dan sljedećeg otvorenog razdoblja te s valjanim datumom dokumenta, ali nevažećim datumom knjiženja ako API odvojeno tretira to dvoje.

Za slučaj zaključanog razdoblja, potvrdite da se zahtjev odbija s dokumentiranom pogreškom zaključavanja razdoblja - 409 conflict u Nordletu - te da se ne zapisuju retci dnevnika, da se ne troši broj dokumenta, da nijedan dokument ne prelazi u stanje knjiženja i da se ne pokreće uspješan webhook. Verzija s otvorenim razdobljem trebala bi uspjeti s istim financijskim vrijednostima.

Test utrke (Race test). Pokrenite knjiženje u otvoreno razdoblje, zaključajte razdoblje usred zahtjeva i potvrdite da izvršenje ne može zaobići zaključavanje. Ključni uvjet prolaza: izvršeno knjiženje nikada ne završava u razdoblju koje je zaključano prije nego što je transakcija potvrđena.

Revizorski trag i usklađivanje

Za svaku uspješnu mutaciju potvrdite da poslovni objekt postoji, da računovodstveni unos postoji s dugovnom stranom jednakom potražnoj, da zapis revizije postoji, da webhook događaj postoji ili se može dohvatiti te da vaš zapis operacije upućuje na ID objekta pružatelja usluge s ponovljenim pokušajima koji upućuju na istu logičnu operaciju.

Za svaku odbijenu mutaciju potvrdite da ne postoji djelomični dokument, da nije potrošen nijedan broj osim ako ugovor dopušta rezervaciju, da ne postoji unos u glavnoj knjizi, da ne postoji uspješan webhook te da pogreška nosi ID zahtjeva za dijagnostiku. Nordletove konvencije opisuju revizorsku ispravnost mutacija i uravnotežena knjiženja kao platformska jamstva, pri čemu ravnotežu provjerava odgođeni okidač baze podataka u trenutku potvrde, a ne samo aplikacijski kod. Pretvorite ta jamstva u upite za naknadno usklađivanje umjesto da vjerujete HTTP odgovoru.

Osnovna matrica testiranja

Područje	Testna radnja	Očekivana provjera	Kriterij prolaza
Autentifikacija	Nema ključa, nevažeći ključ, nedovoljan opseg	Strukturirani 401/403; nema nuspojava	Svi odbijeni pokušaji ne stvaraju računovodstveni zapis
Shema i novac	Nevažeća decimala, datum, obavezno polje	Pogreška provjere valjanosti na razini polja	Nema ponovljenih pokušaja ni djelomičnog upisa
Normalno knjiženje	Kreiranje i izdavanje fakture u otvorenom razdoblju	Jedan dokument, jedan uravnoteženi dnevnik, jedan zapis revizije	Stanje ponovnog čitanja i glavna knjiga se podudaraju
Ponavljanje s istim ključem	Ponavljanje identične mutacije, isti ključ i tijelo	Izvorni rezultat ponovljen; nema duplikata	ID objekta, broj, učinak dnevnika, revizija ostaju jedinstveni
Promijenjeno tijelo, isti ključ	Ponovna upotreba ključa s drugim iznosom	Dokumentirano odbijanje ponovne upotrebe ključa	Izvorni zapis nepromijenjen; ništa novo nije upisano
Puknuta veza	Izvršenje, prekid, ponavljanje s istim ključem	Ponovljeni rezultat	Točno jedna financijska nuspojava
Zaključano razdoblje	Knjiženje dokumenta datiranog u zaključano razdoblje	Odbijanje zbog zaključanog razdoblja	Nema dnevnika, nema broja, nema uspješnog webhooka
Potpis webhooka	Krivi tajni ključ, izmijenjeno tijelo	Odgovor koji nije 2xx s primatelja	Prihvaćeni samo ispravno izvorno tijelo i tajni ključ

Što bih prvo učinio

Ako imate malo vremena, pokrenite testove redoslijedom koji hvata najskuplje pogreške. Počnite s ponovnim pokušajem nakon puknute veze, jer taj jedan scenarij proizvodi većinu stvarnih duplikata. Zatim par idempotencije s istim ključem i promijenjenim tijelom. Zatim zaključana razdoblja, budući da je knjiženje u zatvorenom mjesecu revizorski problem koji se kasno otkriva. Provjera potpisa i webhooks izvan redoslijeda dolaze sljedeći, a puna shema i matrica autorizacije mogu se kontinuirano izvoditi u CI-ju jednom kada se klijent stabilizira.

Sve ostalo u ovom planu podržava ovih pet stavki. Neka one prođu u sandbox tvrtki, uz čitanja usklađivanja koja potvrđuju nuspojave, i znat ćete da je integracija sigurna prije nego što dotakne ijednu stvarnu glavnu knjigu. Možete kreirati sandbox tvrtku i testni ključ s ograničenim opsegom u nekoliko minuta s stranice Početak rada, te provjeriti koji vam moduli trebaju uz popis značajki.

FAQ

Je li odgovor 2xx dovoljan da se potvrdi uspješnost računovodstvenog upisa?

Ne. Kod statusa potvrđuje da je poslužitelj odgovorio, a ne da postoje točno jedan dokument, jedna dodjela broja i jedan uravnoteženi unos u dnevnik. Svaki test mutacije trebao bi nakon odgovora sadržavati ponovno čitanje objekta, njegovog računovodstvenog učinka i zapisa revizije. Opasan slučaj je suprotan smjer: operacija koja je izvršena, dok klijent uopće nije primio odgovor.

Trebam li generirati novi ključ idempotencije kada istekne vrijeme zahtjeva (timeout)?

Ne, a to je pogreška koja uzrokuje većinu produkcijskih duplikata. Ključ identificira logičnu poslovnu operaciju, a ne mrežni pokušaj. Ponovite isti ključ, a zatim uskladite stanje čitanjem resursa. Biblioteka za ponavljanje koja stvara svježi UUID pri svakom pokušaju pretvara jednu namjeravanu fakturu u nekoliko neovisnih upisa.

Što se događa ako ponovno upotrijebim ključ idempotencije s drugim podacima (payload)?

Ispravan API to odbija umjesto da tiho primjenjuje novo tijelo. Nordlet vraća 422 idempotency_key_reuse i ostavlja izvorni zapis netaknutim. Vaš bi klijent to trebao tretirati kao programsku pogrešku koju treba ispraviti, a ne kao stanje koje treba riješiti generiranjem novog ključa.

Jesu li webhooks zamjena za ponovno čitanje kreiranog objekta?

Ne. Dostava webhooka dokazuje naknadnu obavijest, a ne da se transakcija izvršila onako kako očekujete, a redoslijed isporuke nije zajamčen. Provjerite potpis nad izvornim tijelom, uklonite duplikate na temelju ID-a isporuke ili događaja i dohvatite trenutačno stanje s API-ja kad god sam redoslijed događaja nije dovoljan da se odluči što se promijenilo.

Kako mogu testirati knjiženje u zaključano računovodstveno razdoblje?

Kreirajte ekvivalentne dokumente u otvorenom i u zaključanom razdoblju te potvrdite da se zaključani slučaj odbija bez redaka dnevnika, bez potrošenog broja dokumenta, bez prijelaza stanja i bez uspješnog webhooka. Zatim pokrenite test utrke: pokrenite knjiženje u otvoreno razdoblje i zaključajte razdoblje usred zahtjeva. Izvršeno knjiženje nikada ne smije završiti u razdoblju koje je zaključano prije nego što je transakcija potvrđena.

Mogu li pokrenuti testove dvostrukih upisa velikog obujma u sandbox tvrtki?

Da. Sandbox tvrtka ponaša se poput stvarne, označena je kao testni podatak i briše se odmah umjesto nakon razdoblja čuvanja, stoga je pravo mjesto za destruktivna testiranja i testiranja duplikata. Korištenje sandbox okruženja se i dalje mjeri i naplaćuje poput stvarnog korištenja, stoga planirajte obujam umjesto da izvodite beskonačne petlje.