Rezerwacja odbiorcy (RO) w Comarch Optima: jak naprawdę działa i gdzie integracje ją psują

Dlaczego to piszę

Google od mniej więcej miesiąca wysyła ludzi na tę stronę z zapytaniem "ro" "rezerwacja odbiorcy". Trafiają na mój tekst o Optimie i portalu B2B, który wspomina o RO w jednym akapicie i idzie dalej. Nie tego szukali. Szukali tego.

RO to dokument, którym Optima obsługuje zamówienie klienta. To także jedyny mechanizm, który przesądza, czy Wasz magazyn nadsprzedaje, czy sklep internetowy pokazuje uczciwe stany i czy integracja, za którą zapłaciliście, po cichu nie sprawia, że towar znika. Większość ludzi, którzy wystawiają RO codziennie, nie potrafiłaby powiedzieć, co ono właściwie trzyma. A większość integratorów, którzy zapisują do niego dane, nigdy nie przeczytała trzech parametrów konfiguracji zmieniających jego znaczenie.

Wszystko poniżej opiera się na dokumentacji samego Comarchu i na instalacjach, które musiałem debugować. Nic tu nie jest zgadywane.

Co RO trzyma, a czego nie

Zacznijmy od zdania, którego używa sam Comarch: rezerwacja nie zdejmuje towaru z magazynu, tylko pomniejsza ilość dostępną do sprzedaży. Na karcie każdego towaru siedzą dwie liczby. Ilość to to, co fizycznie leży w magazynie. Ilość dostępna to ta liczba pomniejszona o rezerwacje. RO zmienia drugą i nie rusza pierwszej.

To cały mechanizm. Arytmetyka, nic więcej. Fizyczny towar opuszcza magazyn, kiedy powstaje WZ albo kiedy faktura lub paragon zapisane są jako pobranie, a nie rezerwacja. Do tego czasu rezerwacja jest liczbą, na którą ktoś gdzieś patrzy albo nie.

Wynikają z tego trzy konsekwencje i każda z nich to realna awaria projektu, którą widziałem.

Rezerwacja blokuje wydanie tylko wtedy, gdy ktoś zaznaczył pole. W Konfiguracji Firmy → Magazyn → Parametry → Zamówienia i Rezerwacje jest parametr Nie pozwalaj na wydanie towaru gdy występują rezerwacje. Wyłączony: program pozwala wydać towar, jeśli tylko w magazynie jest wystarczająca fizyczna ilość, rezerwacje czy nie. Włączony: wydanie zostaje zablokowane, gdy ilość dostępna jest niewystarczająca z powodu istniejących rezerwacji. Comarch przedstawia to jako dwa równoprawne sposoby prowadzenia magazynu. W porządku. Ale to oznacza, że na instalacji z wyłączonym parametrem RO jest notatką na tablicy, a nie kłódką na regale. WZ dla innego klienta może wyjechać z zarezerwowanym towarem i Optima nie powie ani słowa.

Zadajcie to pytanie pierwszego dnia każdego projektu z Optimą: czy parametr blokady jest włączony? Ani razu nie zdarzyło mi się, żeby klient znał odpowiedź bez sprawdzania.

Rezerwacja ma zegar. Każde RO nosi dwie daty: Data wystawienia, od której towar jest zarezerwowany, i Termin rezerwacji, po którym już nie jest. Dokumentacja Comarchu mówi o tym bez owijania: towary z przeterminowanych rezerwacji zostają odblokowane i zwiększają ilość dostępną. Dokument pozostaje otwarty. Nadal jest na liście RO, nadal widać go u kontrahenta, nadal siedzi na zakładce Rezerwacje karty towaru oznaczony jako przeterminowany. Ale nie trzyma już niczego.

Przeterminowane RO łączy najgorsze cechy obu stanów. Klient wciąż czeka na towar. Handlowiec wciąż widzi otwarte zamówienie. A towar może wziąć każdy, kto poprosi pierwszy.

Domyślny termin to liczba dni w Konfiguracji Firmy → Handel → Parametry, liczona od daty wystawienia. Sprawdźcie, ile wynosi na instalacji, z którą się integrujecie. I zwróćcie uwagę na wyjątek, który ma znaczenie dla integratorów: przy RO importowanych z XML ustawienie z konfiguracji w ogóle nie ma zastosowania, termin zawsze pochodzi z pliku. Ten zegar trzyma Wasza integracja. Jeśli wpisuje termin, o którym nikt nie pomyślał, rezerwacja może wygasnąć, zanim zobaczy ją magazynier.

Zatwierdzonego RO nie da się edytować. Zatwierdzonego dokumentu RO nie można korygować. Są dwie wspierane ścieżki. Zamknąć, opcjonalnie przez Zamknij i wygeneruj RO różnicowe, co tworzy w buforze nowe RO tylko z niezrealizowanymi pozycjami i ilościami, powiązane ze źródłem. Albo anulować, co jest możliwe dopiero po anulowaniu lub usunięciu wszystkich dokumentów wynikowych. Żadna z nich nie jest edycją.

Każdy sklep internetowy, każdy portal B2B i każda aplikacja handlowca pozwala klientowi zmienić zamówienie po złożeniu. Każda integracja musi więc zdecydować, na piśmie, którą z tych dwóch ścieżek wybiera i kiedy. Te, które nigdy nie zdecydowały, kończą z dwoma RO trzymającymi towar pod jedno zamówienie.

Cykl życia, żeby dało się o tym rozumować

Statusy na liście RO to maszyna stanów. Znajcie je na pamięć, bo każdy błąd integracji, jaki tropiłem, sprowadza się do jednego przejścia między nimi.

• Pusty status: zatwierdzone, jeszcze niezrealizowane, niepowiązane z proformą.
• PF: niezrealizowane, powiązane z fakturą pro forma.
• W realizacji: częściowo przekształcone do dokumentów wynikowych.
• Zrealizowano: przekształcone w całości. Nic więcej się z nim nie zrobi.
• Zamknięto: zamknięte przez człowieka, niezależnie od tego, co zrealizowano. Rezerwacje znikają z list zasobów.
• Anulowano: anulowane.

Dwie kolumny pojawiają się na dokumencie dopiero po zapisie na trwałe: Zrealizowano, ilość już przeciągnięta do WZ, FS lub PA, oraz Pozostaje, czyli to, co jeszcze podlega przekształceniu. Dokument zamknięty w ogóle nie pokazuje kolumny Pozostaje. To sygnał dla integracji czytającej listę RO: jeśli sami liczycie „pozostałą ilość" z pozycji, na każdym zamkniętym dokumencie już się mylicie.

Przekształcenia idą do FS, PA, WZ, RW, MM, FPF i ZD. Dwie reguły dają się we znaki w praktyce. WZ zdejmuje towar natychmiast, więc wymaga fizycznego stanu na każdej pozycji, a jeśli choć jednej pozycji brakuje, WZ nie powstanie wcale. I RO da się przekształcić do paragonu tylko wtedy, gdy było liczone od brutto, a to pole (Dokument liczony od) integracja wystawiająca RO musi ustawić świadomie.

Pole, na które wskazałbym każdemu integratorowi, jest najmniejsze na formularzu: Numer zamówienia, zewnętrzny numer zamówienia. To naturalne miejsce na własny identyfikator zamówienia ze sklepu lub portalu, to sposób na idempotentny import, a przy przekształceniu przechodzi do opisu dokumentu wynikowego. Używajcie go, a zdublowany import stanie się zapytaniem, a nie zagadką.

Gdzie to się sypie w integracjach

W przewodniku programisty po Optimie wymieniłem semantykę rezerwacji jako jedno z pięciu miejsc, w których integracje z Optimą się psują. Oto dłuższa wersja.

Jedno RO na koszyk. Sklep albo portal tworzy RO w momencie, gdy klient wrzuca towar do koszyka, „żeby stan był zablokowany". Każdy porzucony koszyk staje się rezerwacją z terminem, którego nikt nie ustawił. W ciągu miesiąca ilość dostępna na bestsellerach jest fikcją, magazyn jest przekonany, że ma problem z ubytkami, a naprawa zajmuje trzy dni, bo nikt nie podejrzewa integracji. RO powinno istnieć tylko dla potwierdzonego zamówienia. Tak robi własny konektor Comarch e-Sklep: importuje zamówienie dopiero, gdy klient je potwierdził i status w sklepie przeszedł na oczekujące na potwierdzenie sklepu, a RO tworzy w buforze.

Zły magazyn. RO rezerwuje towar w jednym magazynie, tym z dokumentu. Konektor e-Sklep ma dokładnie na to ustawienie magazynu domyślnego, a gdy jest puste, rezerwacja trafia do magazynu operatora albo głównego. Portal, który rezerwuje w magazynie głównym, podczas gdy towar wydawany jest z drugiego, trzyma powietrze.

Która liczba idzie do sklepu. To pytanie zadałbym przed wszystkimi innymi. Konektor Comarchu ma pole wyboru Stany na dzień. Zaznaczone: wysyła Ilość dostępną, liczbę skorygowaną o rezerwacje. Niezaznaczone: wysyła stan całkowity. To jedno pole to cała Wasza polityka nadsprzedaży. Stan całkowity oznacza, że każde otwarte RO to obietnica, którą można złamać dwa razy, raz w sklepie i raz w magazynie. Ilość dostępna oznacza, że tym, co widać w sklepie, zaczyna rządzić problem przeterminowanych rezerwacji z poprzedniej sekcji. To drugie i tak jest właściwym wyborem. Tylko że przychodzi z obowiązkiem utrzymania.

Edycje, które tworzą zamiast zastępować. Opisane wyżej. Portal wysyła zaktualizowane zamówienie, integracja tworzy drugie RO, pierwsze trzyma towar do końca terminu, a do tego czasu klient już usłyszał, że towaru nie ma.

Rezerwacje, których integracja nie widzi. Ilość dostępną pomniejsza więcej niż RO. Niezapłacone faktury i paragony zapisane jako rezerwacja trzymają towar bez żadnego terminu, tak samo zlecenia serwisowe z dostawami przypisanymi do części. Integracja, która czyta RO, żeby odtworzyć „co jest zarezerwowane", nigdy nie zejdzie się z ilością dostępną, którą pokazuje sama Optima. Czytajcie liczbę, którą Optima liczy. Nie liczcie jej sami.

Audyt na godzinę

To sprawdzenie, które robię, zanim cokolwiek zaproponuję na instalacji Optimy, i które chciałbym, żeby każda hurtownia robiła raz w miesiącu. Kosztuje jeden eksport i jedno sortowanie. Porównajcie z audytem nieaktualności limitów kredytowych, który opisałem dla enova365, ma ten sam kształt.

Otwórzcie listę RO. Ustawcie Rodzaj na rezerwacje do zrealizowania. Włączcie filtr Przeterminowane, żeby dokumenty po terminie były na liście. Wyeksportujcie z terminem i kolumną Pozostaje.

Potem trzy liczby:

1. Udział otwartych RO po terminie. Każde z nich to zamówienie, którego klient oczekuje, a które nie trzyma już żadnego towaru. Na instalacjach, gdzie domyślnej liczby dni nikt nie ustawił z namysłem, widziałem wartości powyżej połowy. To nie jest problem magazynu, tylko problem konfiguracji, który wygląda jak problem magazynu.
2. Otwarte RO starsze niż najdłuższy czas dostawy. Zamówienia, które tygodnie temu powinny były zamienić się w WZ albo ZD i nie zrobiły nic. Zwykle klient zmienił zdanie przez telefon i nikt nie zamknął dokumentu.
3. RO w buforze starsze niż dzień. Importy, które przyszły i nigdy nie zostały zatwierdzone. Konektor e-Sklep wkłada każde zamówienie do bufora, a dokument w buforze to rezerwacja, która jeszcze nie jest rezerwacją.

Pierwsza liczba mówi, czy ilość dostępna na tej instalacji cokolwiek znaczy. Jeśli jest wysoka, nie podłączajcie do niej sklepu, dopóki nie zostanie naprawiona, bo będziecie eksportować fikcję.

Co tu robi agent, a czego nie wolno mu robić

To przypadek, w którym granica między czytaniem a decydowaniem jest wyjątkowo wyraźna, i właśnie dlatego to dobra pierwsza automatyzacja.

Strona odczytu to sam zysk. Nocne zadanie, które pobiera listę RO i raportuje trzy liczby powyżej. Które flaguje każde RO z terminem w ciągu dwóch najbliższych dni i niezrealizowaną ilością. I które wskazuje RO, których pozycji nie pokrywa fizyczny stan i które nie mają powiązanego ZD. To ostatnie zwraca się najszybciej: rezerwacja na towar, którego nie ma i którego nikt nie zamówił u dostawcy, to zamówienie, które będzie spóźnione, a dziś nikt się o tym nie dowiaduje, dopóki nie trafi na to magazynier.

Strona zapisu to miejsce, w którym się zatrzymuję. Przedłużenie terminu to decyzja handlowa o tym, czyje zamówienie jest ważniejsze. Zamknięcie RO to powiedzenie klientowi „nie". Wygenerowanie ZD angażuje pieniądze. Każdą z tych rzeczy agent może położyć przed człowiekiem jako propozycję z całą sprawą w załączniku. Żadnej nie powinien robić sam. To ta sama zasada „najpierw odczyt, człowiek przy każdym zapisie", którą opisałem przy agentach dla enova365, i tu obowiązuje z większą siłą, bo przedmiotem decyzji jest fizyczny towar.

Jest też metryka warta uruchomienia od pierwszego tygodnia: liczba RO zamkniętych lub anulowanych na sto utworzonych. Wysoka oznacza, że zamówienia są składane i wycofywane bez przerwy, a tego nie naprawi żadne ustawienie rezerwacji, bo to problem procesu sprzedaży. Niska przy wysokim udziale przeterminowanych oznacza, że zamówienia są prawdziwe, terminy są złe i jedna zmiana w konfiguracji przesuwa cały obraz.

Dokąd to prowadzi

RO to most między tym, jak klient zamawia, a tym, co robi z tym magazyn, i przekracza go każdy kanał zasilający Optimę: sklep, portal B2B, telefon handlowca, mail z zamówieniem, które ktoś przepisuje ręcznie. Właściwa semantyka rezerwacji to różnica między portalem, który pokazuje uczciwe stany, a takim, który uczy klientów, żeby dzwonić i sprawdzać.

Jeśli szacujecie integrację z Optimą i chcecie, żeby ktoś zrobił ten godzinny audyt na Waszych prawdziwych danych, zanim ktokolwiek napisze linijkę kodu, odezwijcie się. To pierwsza rzecz, którą robię w każdym projekcie agentów AI dla firm na Optimie, tak samo jak przy integracjach z enova365, i zwykle właśnie ona zmienia zakres.