IOSOR

IOSOR Znanje

Redoslijed događaja u odnosu na knjiženje u glavnoj knjizi

DLR i MO događaji izvan redoslijeda ne smiju narušiti pravila knjiženja prepaid terećenja — redoslijed prispijeća nije novčani zakon.

Mreže isporučuju povratne pozive izvan redoslijeda. Kasni DLR, rani MO ili promjena statusa prije poravnanja ne smiju izmisliti drugo terećenje niti prepisati već poravnati redak. Ova stranica predstavlja ugovor o redoslijedu knjiženja: pravila glavne knjige preživljavaju preuređivanje — ovo nije uvod u ID-eve korelacije niti esej o naplati MO u odnosu na MT.

Redoslijed prispijeća nije zakon glavne knjige

HTTP prispijeće je prometna nezgoda. Novac se knjiži pod stanjem zadržavanja → poravnanje → ažuriranje ishoda — a ne prema tome «koji je povratni poziv zadnji sletio». Blagih USD 1 000/mjesečno tretira preuređivanje kao financijski incident kada proizvod prikazuje uspjeh dok se glavna knjiga dvaput pomiče. USD 20 dokazuje da prisilni kasni DLR nikada ne otvara paralelno terećenje. Ponavljanja istog ID-ja: Duplikat webhook poruke ne smije stvoriti drugo terećenje.

Kako izgleda nered u redoslijedu

Obrazac dolaska Sigurno knjiženje Nesigurna reakcija
DLR prije poravnanja Na čekanju; poravnati jednom pod držanjem Terećenje samo iz DLR-a
Neuspjelo pa isporučeno Ažurirati ishod na licu mjesta Druga naplata za preokret
MO prije MT korelacije Arhivirati u ulaznu poštu; spojiti na MT poravnanje Naplatiti MO kao izlaznu poruku
Status nakon povrata Nema novog novca; označiti Ponovno poravnati oslobođenu namjeru
Dva terminala, jedna namjera Jedan red novca Dva retka terećenja

Pravila knjiženja koja preživljavaju preuređivanje

Generirajte ključeve zadržavanja i idempotencije prije nuspojava (Webhook ugovor prije prvog slanja). Poravnajte jednom po naplativoj namjeri; kasniji događaji ažuriraju samo ishod. Nikada ne otvarajte paralelno terećenje za rani ili kasni DLR ili MO. Odbacite ili parkirajte izvan potpisanog prozora — nema izmišljenog uspjeha. Izvoz se spaja po namjeri — a ne po vremenskoj oznaci dolaska.

Kašnjenje je normalno, dvostruki novac nije

Kada mreža isporuči kasni DLR nakon što je poravnanje završeno, glavna knjiga mora ostati netaknuta. Sustav zaključava stanje i ignorira kasne promjene smjera. Nadzorna ploča se može zbuniti, ali stanje računa ne smije patiti od kašnjenja u transportu. Računalni resursi služe za očuvanje točnosti, a ne za usklađivanje kašnjenja u mreži. Poznavanje ovih pravila sprječava financijske rupe prije nego što postanu kritične za poslovanje.

Kontrolni popis kupca za redoslijed događaja

Provjerite jesu li vaši webhukovi idempotentni i koriste li ispravne ključeve zadržavanja. Osigurajte da sustav za naplatu nikada ne otvara novi debet na temelju kasnih statusa dostave. Pratite metrike kašnjenja kako biste uočili mrežne anomalije prije nego što utjecaj na novac postane preveliki problem. Usporedite dolazne poruke s izvornom namjerom, a ne s redoslijedom kojim su sletjele na poslužitelj.

Počnite s IOSOR-om

U konzoli: Event order vs ledger posting must reconcile by shared id.. Imenujte vlasnika i kapije prije širenja.

Povezano: duplicate webhook no second debit webhook consumer ops at volume

Sažetak IOSOR

Ops disciplina za dežurstvo—ne brochure.

Radite: name owner + gate. Ne: skip the gate.

Je li vam ovaj vodič pomogao?

Povezani vodiči