IOSOR

IOSOR Wiedza

Korelacja ID dla debetów i DLR

Połącz wiersz debetu prepaid z wydarzeniem dostarczenia za pomocą jednego stabilnego identyfikatora korelacji — finanse i produkt dzielą ten sam cel bez archeologii danych.

Kiedy pieniądze i dostawy żyją w osobnych narzędziach, koniec miesiąca staje się archeologicznym wykopaliskiem. Korelacja ID to stabilny klucz łączący wiersz debetu prepaid z DLR (lub statusem końcowym) dla tego samego celu. Bez niego finanse widzą wydatki, a produkt status — żadna strona nie może udowodnić, że opisują jedną wysyłkę. Ta strona to kontrakt łączenia, a nie podręcznik eksportu sesji Verify czy elementarz księgi debet-vs-status.

Korelacja to nie wątek na czacie

Linki ze Slacka i tytuły ticketów nie są kluczami łączenia. ID musi być wygenerowane przy tworzeniu hold/intent, przeniesione na wiersz debetu i powtórzone na każdym końcowym DLR/statusie. Ponowne próby używają tego samego ID pod tym samym kluczem idempotencji. Jeśli support wkleja inny ciąg znaków co godzinę, nie masz korelacji — masz folklor.

To samo ID na debecie i DLR

Powierzchnia Musi zawierać Błąd przy braku
Prepaid debit / hold Korelacja + intent id Niepołączalny wydatek
DLR / status To samo ID korelacji Sierocy event dostawy
Wiersz eksportu Ops Oba + status końcowy Recon z pamięci

Produkt i finanse otwierają ten sam ID dla tego samego okna UTC. Dostarczony DLR bez pasującego debetu — lub rozliczony debet bez statusu końcowego — to incydent, a nie ostrzeżenie.

Łączenie finansowe bez archeologii

Koniec miesiąca powinien filtrować jedną kolumnę, a nie rekonstruować zrzuty ekranu. Eksport: korelacja id, kwota debetu (USD), hold→settle, status końcowy, znaczniki czasu. Miękkie USD 1.000/miesiąc traktuje niedopasowane połączenia jako tickety rozliczeniowe; USD 20 dowodzi połączenia na małym korytarzu przed językiem wolumenu.

Brak połączenia to incydent

Nie mapuj automatycznie sierocego DLR do dostarczonych wydatków i nie rozliczaj debetów z pustym ID jako 'prawdopodobnie w porządku'. Otwórz recon, zachowaj uczciwość statusu (brakujący/nieznany do czasu połączenia lub zamknięcia) i blokuj język 'Live volume', gdy zdrowie łączenia jest czerwone na Tablica sygnałów operacyjnych przy wolumenie.

Lista kontrolna dla korelacji ID

  1. Czy ID korelacji jest tworzone przy oryginalnym zamiarze, a nie przez czat?
  2. Czy ID jest zachowane przy wszystkich ponownych próbach pod tym samym kluczem idempotencji?
  3. Czy system eksportu finansowego przechwytuje ID korelacji jako główną kolumnę łączenia?

Start z IOSOR

Utwórzcie correlation ID przy hold, wpiszcie je na wiersz obciążenia prepaid i wymagajcie tego samego łańcucha na końcowym DLR. Eksportujcie jeden połączony wiersz: id hold, kwota obciążenia, status DLR, znaczki. Każde obciążenie bez pasującego DLR — albo DLR bez obciążenia — zostaje incydentem. To złączenie pieniędzy i pokwitowania, nie ślad żądania.

Podsumowanie IOSOR

Obciążenie i DLR dzielą jeden ID, inaczej finanse nie zaudytują wysyłki.

Róbcie: wygenerujcie ID przy hold i odrzucajcie niesparowane złączenia jako incydenty.

Nie róbcie: wymyślać nowego łańcucha przy webhooku ani składać końca miesiąca z wątków czatu.

Czy ten przewodnik był pomocny?

Powiązane przewodniki