--- title: "Agent, który pisze do ERP: granica między odczytem a zapisem" url: "https://hurukan.com/pl/blog/agent-ktory-pisze-do-erp" description: "Odczyt z systemu zapisu jest tani i bezpieczny. Zapis zwrotny to miejsce, w którym psują się integracje. Co musi istnieć, zanim agent cokolwiek zapisze." --- # Agent, który pisze do ERP: granica między odczytem a zapisem 20 października 2026·4 min czytania·Redakcja Pracownik księgowości widziany z boku przy biurku z dwoma monitorami, na jednym abstrakcyjna niebiesko-szara księga, dłoń na myszy, wydrukowany dokument przyłożony do ekranu dla porównania, chłodne biurowe światło Dział zakupów prowadzi pilotaż. Agent czyta otwarte zapotrzebowania, stany magazynowe i czasy dostaw, i przez trzy tygodnie robi to, na co wszyscy liczyli: proponuje zamówienia, kupcy je sprawdzają, kupcy wklepują je do ERP. Potem ktoś zadaje oczywiste pytanie. Po co przepisujemy to, co agent już przygotował? Dajmy mu prawo zapisu. W poniedziałek rano ERP pokazuje dwa zamówienia do tego samego dostawcy, te same pozycje, dwie minuty różnicy. Jedno ma podpięte potwierdzenie od dostawcy. Drugie poniżej nagłówka jest puste. Łącznik przy pierwszej próbie dostał przekroczenie czasu i spróbował ponownie; ERP przyjął obie połowy tej historii. Dostawca zaczął już kompletować według jednego z nich i nikt w pokoju nie umie powiedzieć którego. W rozumowaniu agenta nie było nic złego. Zawiódł zapis, a zapis to miejsce, w którym integracje zawodzą od dwudziestu lat. Odczyt z systemu zapisu jest problemem rozwiązanym i niemal pozbawionym ryzyka: odczyt można powtórzyć, zbuforować, porównać i wyrzucić. Zapis zmienia rekord, który reszta firmy traktuje jako prawdę, a rekord nie ma jak wiedzieć, czy zmiana była zamierzona raz czy dwa razy. ## Dlaczego zapis zwrotny to inny problem **Odczyt da się powtórzyć; zapisu nie.** Jeśli odczyt pada w połowie, czytamy jeszcze raz. Jeśli zapis pada w połowie, mamy dokument, który istnieje częściowo, a następna próba albo dubluje to, co weszło, albo pomija to, co nie weszło. Każde uzgodnienie na koniec miesiąca istnieje z powodu tej asymetrii. **Zapis częściowy jest gorszy niż brak zapisu.** Zamówienie z nagłówkiem i bez pozycji przechodzi walidację ERP. Blokuje też numer u dostawcy, pojawia się w otwartych zobowiązaniach i trafia do następnego raportu. Awaria jest niewidoczna dokładnie tam, gdzie ma znaczenie. **W systemie zapisu nie ma cofania.** Oprogramowanie księgowe jest zaprojektowane tak, żeby niczego nie usuwać. Błędne księgowanie poprawia się stornem, błędną fakturę korektą. Każda poprawka to nowy dokument z własnym numerem i własnym śladem, więc pomyłka zrobiona w tempie maszyny zostawia gruz w tempie maszyny, który człowiek sprząta ręcznie. **Przekroczenie czasu zamienia jedną intencję w dwa działania.** Łącznik nie wie, czy system dostał żądanie i wolno odpowiadał, czy nie dostał go wcale. Bez sposobu na powiedzenie „to jest to samo żądanie co przed chwilą” wybór bezpieczny i wybór poprawny wskazują w przeciwne strony. **Zapis omija znaczenie.** ERP sprawdza, czy pola są wypełnione i czy kody istnieją. Nie wie, że ten klient ma blokadę kredytową ustaloną na spotkaniu ani że ten dostawca może być używany tylko dla jednego zakładu. Te reguły mieszkają w ludziach, a bezpośredni zapis przechodzi obok nich. **Nikt nie umie powiedzieć, kto to zapisał.** Użytkownik integracyjny, który założył zamówienie, to konto techniczne wspólne dla każdego procesu, który przez nie przechodzi. Pytanie „kto o tym zdecydował” nie ma w rekordzie odpowiedzi; o tym jest [jedna tożsamość dla ludzi i agentów](https://hurukan.com/pl/blog/jedna-tozsamosc-dla-ludzi-i-agentow). ## Co musi istnieć, zanim agent zapisze **Idempotentne propozycje.** Każda zamierzona zmiana niesie jeden identyfikator, nadany przed pierwszą próbą. Wysłana dwa razy musi dać jeden wynik, a strona odbierająca musi umieć powiedzieć „już zrobione”, zamiast robić to ponownie. Jeśli system docelowy tego nie potrafi, musi to zapewnić warstwa przed nim: sprawdzić, zanim wyśle, i zapisać, co wysłała. **Krok zatwierdzenia, który ma właściciela.** Nie powiadomienie, tylko decyzja: propozycja, dowody za nią i ryzyko, które niesie, zatwierdzone, zmienione albo odrzucone przez kogoś, czyje nazwisko trafia do rekordu. Które zapisy tego wymagają, nie jest kwestią gustu; jest spisane dla każdego działania, a wychodzące pieniądze i podjęte zobowiązanie są na tej liście zawsze. **Rejestr, który da się odtworzyć.** Co agent zobaczył, co wywnioskował, co zaproponował, kto zatwierdził, co wysłano, co wróciło. Zapisany tak, żeby po miesiącach człowiek mógł prześledzić łańcuch, i ustrukturyzowany tak, żeby dało się go odegrać na kopii systemu, gdy coś trzeba odtworzyć. **Granica, którą ontologia czyni jawną.** Działania istniejące na każdym obiekcie biznesowym, stany, w jakich obiekt może być, reguły, które zmiana musi spełnić, i to, które działania są krytyczne. Agent działający wyłącznie w tych pojęciach nie zapisze niczego, na co model nie pozwala, a człowiek czytający model widzi dokładnie, co agentowi wolno. **Uzgodnienie po zapisie.** Odczytać, co wylądowało, i porównać z tym, co wysłano. Większość podwójnych księgowań znajduje dostawca albo audytor; powinien je znajdować system, który je zrobił, w ciągu minut. ## Test, który możecie zrobić dziś Weźcie najnowszą integrację, która zapisuje do Waszego ERP albo programu księgowego. Nie musi dotyczyć agenta; wystarczy łącznik sklepu internetowego albo import z arkusza. Zadajcie ludziom, którzy ją budowali, trzy pytania i spiszcie odpowiedzi. Co się dzieje, gdy ten sam komunikat przyjdzie dwa razy? Co się dzieje, gdy transfer pada po trzeciej pozycji z siedmiu? Gdzie jest zapisane, kto zatwierdził dokument, który został zapisany, i na podstawie jakich dowodów? Potem, jeśli macie środowisko testowe, sprawdźcie dwa pierwsze. Wyślijcie jeden dokument dwa razy i przerwijcie jeden transfer. Policzcie poprawki potrzebne, żeby rekord wrócił do prawdy. Jeśli którakolwiek odpowiedź brzmi „dowiedzielibyśmy się od dostawcy” albo „zobaczylibyśmy to na koniec miesiąca”, integracja nie jest gotowa na agenta, niezależnie od tego, ile agent potrafi przeczytać. Luka nie jest w modelu; jest w ścieżce zapisu i jest taka sama dla człowieka i dla oprogramowania. Hurukan stawia tu własną granicę. Agenci przygotowują, szkicują i proponują w spisanych granicach i działają wyłącznie w pojęciach, które definiuje ontologia. To, co wychodzi do programu księgowego albo do istniejącego systemu utrzymywanego obok, wychodzi po zatwierdzeniu przez człowieka, przez łącznik, z propozycją, decyzją i wynikiem w jednym rejestrze. Operacje krytyczne czekają na człowieka w każdej konfiguracji. Dlaczego systemowi zapisu nie można powierzyć samodzielnego działania, wyjaśnia [System zapisu nie umie działać](https://hurukan.com/pl/blog/system-zapisu-nie-umie-dzialac); dlaczego zapis trzeba obsłużyć aż tak ostrożnie, jest tematem tego tekstu i miejscem, od którego zaczyna [Hurukan](https://hurukan.com/pl). - system zapisu - ERP - agenci - idempotentność - zatwierdzanie ## Czytaj dalej - [Jedna tożsamość dla ludzi i agentów: kto co może](https://hurukan.com/pl/blog/jedna-tozsamosc-dla-ludzi-i-agentow) - [Stan bieżący i zapis: dwie pamięci systemu operacyjnego firmy](https://hurukan.com/pl/blog/stan-biezacy-i-zapis-dwie-pamieci-systemu-operacyjnego-firmy)