Weryfikacja kontrahenta w systemie ERP — jak zaprojektować integrację

Trzy momenty, w których pytanie ma sens

Przy zakładaniu kartoteki. Podstawowa tożsamość: czy podmiot istnieje, jaka jest nazwa i adres, czy NIP się zgadza. To pytanie o poprawność danych, nie o ryzyko.

Przed płatnością. Status VAT i rachunek bankowy — na dzień zlecenia przelewu, nie na dzień założenia kartoteki. Rachunek mógł zostać dopisany albo usunięty w międzyczasie.

Cyklicznie, dla całego portfela. Wpisy o niewypłacalności, zmiana właściciela, trafienie na listę sankcyjną. Tego nie wykryjesz pytaniem jednorazowym, bo zdarza się po nawiązaniu współpracy.

Co cache'ować, a czego nie

Rejestry zmieniają się w różnym tempie i to powinno rządzić czasem życia cache:

• Tożsamość i PKD — zmieniają się rzadko, można trzymać dniami.
• Status VAT i rachunki — zmieniają się codziennie; przed przelewem pytaj świeżo albo z indeksu odświeżanego dobowo.
• Beneficjenci rzeczywiści — zmiana jest rzadka, ale dane wrażliwe; trzymaj krócej, niż pozwalałaby zmienność.
• Wpisy o niewypłacalności — to sygnał, na którym opierasz decyzję; stary odczyt jest gorszy niż jego brak.

Dobra zasada: cache jest po to, żeby nie zamęczać rejestru, a nie po to, żeby udawać, że dane są aktualne. Każda odpowiedź powinna nieść datę ważności danych, a interfejs powinien ją pokazywać.

Niedostępność rejestru to stan, nie błąd

Rejestr publiczny bywa niedostępny — przerwa techniczna, limit, awaria. System musi umieć zapisać „nie wiem” i ponowić później. Sklejenie tego z „brak wpisu” tworzy fałszywe potwierdzenia, które trafiają do dokumentacji. Rozwinęliśmy to osobno: not_found kontra unavailable.

Praktycznie: w modelu danych rozdziel „sprawdzone, czysto” od „nie udało się sprawdzić”. Jeden boolean nie wystarczy.

Co zapisać, żeby dało się udowodnić

Jeśli weryfikacja ma być dowodem należytej staranności, musi zostawić ślad odporny na pytanie „a skąd wiadomo, że sprawdziliście”:

• kiedy pytano i o co (identyfikator podmiotu),
• które źródło odpowiedziało i z jaką datą ważności danych,
• jaka była treść odpowiedzi, a nie tylko wniosek z niej,
• które źródła były niedostępne.

Zapis „sprawdzono: OK” nie jest dowodem. Dowodem jest zamrożona treść odpowiedzi z datą i wskazaniem źródła.

Wolumen i idempotencja

Import dwustu kontrahentów to dwieście zapytań — chyba że API przyjmuje paczki. Warto sprawdzić, czy ponowienie tej samej operacji nie policzy się drugi raz i czy przerwany import da się wznowić bez duplikatów. Przy integracji wsadowej to różnica między spokojnym wdrożeniem a nocą z ręcznym sprzątaniem danych.

Gdzie to wpiąć

Najprościej: jedno wywołanie HTTP w miejscu, gdzie ERP zakłada kartotekę, drugie w ścieżce płatności, trzecie w zadaniu cyklicznym dla całego portfela. Reszta — mosty między identyfikatorami, budżety zapytań, ujednolicona koperta — powinna być poza Twoim kodem.

Kontrakt i przykłady: dokumentacja Rejestry API.

Materiał ma charakter informacyjny i techniczny, nie stanowi porady prawnej ani podatkowej. Zakres obowiązków dokumentacyjnych zależy od branży i przepisów, którym podlega konkretny podmiot.