IOSOR Guide

ID di correlazione tra debito e DLR

Collega la riga di addebito prepagato all'evento di consegna con un ID di correlazione stabile: finanza e prodotto condividono la stessa intenzione senza archeologia.

Quando il denaro e la consegna vivono in strumenti separati, la chiusura mensile diventa archeologia di chat. Un ID di correlazione è la chiave di join stabile che lega la riga di addebito prepagato al DLR (o evento di stato firmato) per la stessa intenzione. Senza di esso, la finanza vede la spesa e il prodotto vede lo stato: nessuno dei due può dimostrare di descrivere un singolo invio. Questa pagina è il contratto di join, non un manuale di esportazione della sessione Verify e non un primer completo del ledger debito-stato.

La correlazione non è una chat

I link di Slack e i titoli dei ticket non sono chiavi di join. L'ID deve essere generato alla creazione dell'hold/intento, trasportato sulla riga di addebito e ripetuto su ogni evento DLR/stato terminale. I tentativi riutilizzano lo stesso ID sotto la stessa chiave di idempotenza. Se il supporto incolla una stringa diversa ogni ora, non hai correlazione: hai folklore.

Stesso ID su debito e DLR

Superficie Deve trasportare Fallimento se mancante
Addebito prepagato / hold Correlazione + ID intento Spesa non joinabile
DLR / stato firmato Stesso ID di correlazione Evento di consegna orfano
Riga export ops Entrambi + parola terminale Recon a memoria

Prodotto e finanza aprono lo stesso ID per la stessa finestra UTC. Un DLR consegnato senza un addebito corrispondente — o un addebito saldato senza uno stato terminale — è un incidente, non un avviso giallo.

Join finanziario senza archeologia

La chiusura mensile dovrebbe filtrare una colonna, non ricostruire da screenshot. Export: ID di correlazione, importo addebito (USD), hold→settle, stato terminale, timestamp. Il limite soft di USD 1.000/mese tratta i join non corrispondenti come ticket di riconciliazione; USD 20 dimostra il join su un piccolo corridoio prima del linguaggio di volume.

Il join mancante è un incidente

Non mappare automaticamente DLR orfani a spesa consegnata e non saldare addebiti con ID vuoto come «probabilmente a posto». Apri la riconciliazione, mantieni lo stato onesto (mancante/sconosciuto finché non viene unito o chiuso con nome) e blocca il linguaggio di «volume attivo» mentre la salute del join è rossa sulla Board di segnali operativi con volume attivo.

Checklist acquirente per ID di correlazione

  1. L'ID di correlazione è generato all'intento originale e non via chat?
  2. L'ID persiste in tutti i tentativi di retry sotto la stessa chiave di idempotenza?
  3. Il sistema di export finanziario cattura l'ID di correlazione come colonna di join primaria?

Inizia con IOSOR

Create il correlation ID al hold, scrivetelo sulla riga di addebito prepagato ed esigete la stessa stringa sul DLR terminale. Esportate una riga unita: id hold, importo addebito, stato DLR, timestamp. Ogni addebito senza DLR coincidente — o un DLR senza addebito — resta un incidente. Questa è una join denaro–ricevuta, non una traccia di richiesta.

Letture: Heartbeat e gate di fumo prima di allertare gli umani Il segnale mancante non è Consegnato.

Sintesi IOSOR

Addebito e DLR condividono un ID altrimenti finance non può auditare l’invio.

Fate: generate l’ID al hold e rifiutate le join senza coppia come incidenti.

Non fate: inventare una nuova stringa al webhook, né ricostruire la chiusura mese dai thread di chat.

Questa guida ti è stata utile?

Guide correlate