Audit log w wymianie danych B2B: dlaczego to nie luksus

W dystrybucji B2B prędzej czy później pojawia się sytuacja: partner kwestionuje cenę, dostępność lub warunki, na bazie których złożył zamówienie. Jego wersja: “dostaliśmy od Was X”. Wasza wersja w ERP: “wysyłaliśmy Y”. Bez audit logu to dyskusja na poziomie “my pamiętamy inaczej”.

To nie problem teoretyczny. Spotykamy go w projektach regularnie i za każdym razem różnica między posiadaniem audit logu a jego brakiem to różnica między 30 sekundami a tygodniem renegocjacji.

sequenceDiagram
  autonumber
  participant P as Partner B2B
  participant API as Warstwa wymiany danych
  participant LOG as Audit log
  participant ERP as ERP (źródło prawdy)
  P->>API: Pobierz ceny i stany
  API->>ERP: Pobierz dane wg reguł partnera
  ERP-->>API: Dane (ceny, stany)
  API->>LOG: Zapis: kto, kiedy, payload + hash (SHA-256)
  API-->>P: Odpowiedź (ceny, stany)
  Note over LOG: Spór? Twardy dowód: timestamp + hash payloadu

Co dokładnie audit log powinien logować

Niejedna firma ma “logi” - tabelę w bazie z zapisem operacji. To nie jest audit log w sensie compliance. Audit log do wymiany danych B2B musi mieć:

1. Timestamp w UTC + strefa systemu - żeby nie tłumaczyć potem o której godzinie czego
2. Partner / odbiorca - kto dostał te dane (ID + nazwa)
3. Kanał - przez co dostał (API call, feed CSV, EDI, push do ERP partnera)
4. Payload hash - SHA-256 dokładnej treści, którą wysłaliście (nie ważne, czy 50 czy 50 000 wierszy)
5. Pełny payload w cold storage (S3, archive bucket) - z TTL np. 12 miesięcy, dla potencjalnego odtworzenia
6. Status doręczenia - 200/4xx/5xx, retry count, czy ostatecznie odebrane
7. Źródło danych - z której tabeli / API call w Waszym ERP / BL pochodzą

Pkt 4 jest kluczowy. Hash pozwala w sekundę zweryfikować, czy partner widzi to samo, co Wy wysłaliście. Bez przesyłania payloadu na nowo, bez zaufania jego wersji.

Trzy momenty, kiedy ratuje życie

Spór handlowy. Partner: “wystawiacie 156 zł, mieliśmy 142”. Sprawdzacie audit log: 2 tygodnie temu wysłaliście do niego payload z ceną 142, hash X. Tydzień temu wysłaliście update - payload z ceną 156, hash Y. Pytanie: na bazie którego payloadu złożył zamówienie? Jeśli na bazie X - wina po Waszej stronie (zła komunikacja zmiany). Jeśli na bazie Y - wina po jego (nie zaktualizował systemu mimo otrzymania nowego feedu). Audit log nie rozstrzyga, kto ma rację, ale daje twarde fakty do rozmowy.

Audyt zewnętrzny. Klient enterprise wymaga, żebyście pokazali, jak Wasza firma traktuje compliance w dystrybucji. Bez audit logu odpowiedź brzmi “ufamy naszemu zespołowi”. Z audit logiem: oto raport, kto dostał jakie dane w ostatnim kwartale, z jakim opóźnieniem, jaki był success rate.

Bug retrospektywny. Trzy tygodnie temu coś się zepsuło - niektórzy partnerzy dostali złe ceny. Bez audit logu: ile, kto, jak duża różnica? Nie wiadomo. Z audit logiem: SELECT z listą poszkodowanych partnerów, kwotami, datami. Można zaproponować korektę zanim ktoś zauważy.

Dlaczego BaseLinker / ERP same tego nie zrobią

Bo to nie ich rola. BL jest platformą e-commerce - ma logi aktywności użytkownika w panelu, ale nie loguje payloadów wychodzących do partnerów B2B z hashem i cold storage. ERP ma logi operacji księgowych, ale nie publikacji danych przez integrację. Audit log wymiany danych jest funkcją warstwy integracyjnej, nie funkcją ERP czy BL.

To dlatego w projektach z poważną dystrybucją B2B przychodzi moment, w którym do BL + ERP dochodzi trzecia warstwa - DataBridge / middleware / iPaaS - która między innymi trzyma ten audit log.

Koszt

Implementacja audit logu w istniejącej integracji to typowo 2-4 tygodnie pracy dewelopera + parę stówek miesięcznie za cold storage (S3 Glacier, podobne). To mniej niż jeden spór z dużym partnerem, który skończył się renegocjacją warunków na bazie “no nie wiemy, kto miał rację”.

Argument “u nas się to nie zdarza” stosuje się dokładnie do momentu, w którym pierwszy raz się zdarza. Wtedy decyzja “dorobimy audit log” zapada w ciągu tygodnia - ale dotyczy już tylko przyszłych incydentów. Te, które już się wydarzyły, zostają nierozstrzygnięte.

W naszej praktyce: audit log od dnia 1, jako część każdego custom DataBridge’a. Nie jako feature, tylko jako część fundamentu.