Problemy ze stanami magazynowymi: diagnoza i naprawa

Gdy sklep pokazuje inną dostępność niż magazyn, zacznij od zakresu incydentu. Zapisz produkty, warianty, kanały i moment wykrycia. Ustal, czy problem dotyczy pojedynczej oferty, jednej integracji czy całego katalogu. Nie wyrównuj od razu wszystkich liczb: można w ten sposób nadpisać poprawne rezerwacje i utrudnić znalezienie przyczyny.

Osoba odpowiedzialna za sprzedaż powinna ocenić ograniczenie przyjmowania kolejnych zamówień dla potwierdzonego problemu. Taką decyzję podejmuje się dla uzasadnionego zakresu, z uwzględnieniem istniejących zobowiązań. Nie zastępuj jej automatycznym zerowaniem całego katalogu po nieudanym imporcie.

Materiał do odtworzenia zdarzenia

Zachowaj eksport stanów, rezerwacji i powiązań oraz właściwy fragment logów. Zanotuj czas odczytu i strefę czasową każdego systemu. Ogranicz dane klientów do niezbędnego minimum i przechowuj materiał w miejscu z odpowiednimi uprawnieniami. Kopia ekranu bez identyfikatora produktu może nie wystarczyć do późniejszego porównania.

Jeżeli doszło do sprzedaży towaru, którego nie można dostarczyć zgodnie z ustaleniami, przekaż sprawę osobie prowadzącej obsługę zamówienia. Potrzebna jest ocena realnych możliwości i obowiązków, bez wymyślonego terminu dostawy lub automatycznej zamiany produktu. Diagnostyka techniczna nie zastępuje opieki nad istniejącą sprawą klienta.

Różne liczby nie zawsze oznaczają błąd. Jeden ekran może pokazywać ilość fizyczną, drugi ilość po odjęciu rezerwacji, a trzeci limit wystawiony w kanale. Przed porównaniem zapisz definicję każdej wartości. Sprawdź też magazyn, jednostkę oraz to, czy uwzględniono towary uszkodzone i oczekujące na kontrolę.

Stan fizyczny opisuje obecność towaru według przyjętej ewidencji i liczenia. Rezerwacja wskazuje ilość przypisaną do określonej potrzeby. Dostępność sprzedażowa wynika z reguł systemu, które mogą uwzględniać rezerwacje, blokady i ograniczenia kanału. Nie używaj jednego pola do wszystkich tych znaczeń bez wyraźnego opisu.

Właściciel osobno dla każdego rodzaju danych

ERP nie musi być nadrzędnym źródłem wszystkiego. Stan może pochodzić z uzgodnionego magazynu, opis ze sklepu, a ceny z osobnego cennika. Dokumentacja Base jako łącznika między magazynami pokazuje również model ze sklepem nadrzędnym i Base jako pośrednikiem. Wybór wymaga określenia kierunków oraz powiązań.

Rozrysuj przepływ dla jednego produktu od przyjęcia do sprzedaży w każdym kanale. Jeśli dwie aplikacje mogą niezależnie nadpisywać to samo pole, zaznacz punkt konfliktu. Podstawy organizacji opisuje poradnik zarządzania magazynem WooCommerce; w incydencie potrzebujesz dodatkowo osi czasu konkretnej rozbieżności.

Wybierz jeden problematyczny produkt i prześledź jego identyfikację w całym przepływie. Zapisz ID sklepu, ID wariantu, SKU, identyfikator w magazynie i numer oferty marketplace. Nazwa handlowa pomaga człowiekowi, ale nie jest wystarczającym kluczem do bezpiecznego powiązania danych.

Nie zakładaj też, że SKU zawsze jednoznacznie rozwiązuje problem. Kod może być pusty, odziedziczony, zmieniony lub różnie zapisany w systemach. Trzeba poznać regułę konkretnego konektora: po czym szuka produktu, kiedy tworzy nowy rekord i co robi przy niejednoznacznym wyniku.

Porównuj tę samą jednostkę

Sprawdź, czy źródło przesyła sztuki, opakowania czy jednostkę wymagającą przeliczenia. Dostawa kartonów i sprzedaż pojedynczych sztuk potrzebują poprawnego mnożnika. Zmiana jednostki w jednym systemie bez aktualizacji integracji może dawać liczby wyglądające wiarygodnie, choć opisują inny zapas.

Zweryfikuj magazyny i lokalizacje. Suma kilku magazynów może obejmować towar niedostępny dla sprzedaży online. Oddziel zapas własny od informacji dostawcy i sprawdź, czy integracja nie dodaje tych samych sztuk dwukrotnie. Dla zestawów ustal, czy dostępność jest liczona ze składników, czy prowadzona osobno.

Zachowaj przykład poprawnego i błędnego mapowania. Porównanie różnic bywa bardziej użyteczne niż przegląd całej konfiguracji bez punktu odniesienia. Jeśli po imporcie powstał nowy produkt zamiast aktualizacji, nie usuwaj go przed odczytaniem historii i powiązań z zamówieniami.

Plan korekty powinien wskazywać dokładne rekordy oraz oczekiwany rezultat. Masowe łączenie po podobnej nazwie może przenieść stan do niewłaściwego wariantu. Najpierw sprawdź mapowanie na kopii i uzgodnij obsługę istniejących odwołań.

Dla wybranego przypadku ułóż chronologicznie zamówienie, rezerwację, potwierdzenie płatności, anulowanie, kompletację, dokument oraz publikację stanu do kanałów. Przy każdym zdarzeniu zapisz identyfikator, źródło i wartość przed zmianą oraz po niej. Sam końcowy status nie pokazuje drogi, która doprowadziła do rozbieżności.

Porównuj czas zdarzenia z czasem jego odebrania. Powiadomienie płatnicze może dotrzeć później niż operacja wykonana przez obsługę. Jeśli patrzysz tylko na kolejność wpisów w jednym panelu, możesz błędnie uznać później zapisany komunikat za nowsze zdarzenie biznesowe.

W WooCommerce ustawienie Hold Stock dotyczy nieopłaconych zamówień Pending payment. Po upływie ustawionego czasu takie zamówienie może zostać anulowane, a stan uwolniony; mechanizm nie dotyczy zamówień On hold. Zakres opisuje dokumentacja ustawień produktów WooCommerce.

Nie utożsamiaj Hold Stock z rezerwacją przy samym wejściu do checkout ani ochroną wszystkich kanałów jednocześnie. Sprawdź statusy, działanie zaplanowanych zadań i wersję integracji. Dopiero konkretny zapis pozwala ocenić, czy problemem było zdarzenie, brak wykonania zadania czy błędna interpretacja pola.

Rozpocznij od wskazania operacji: pobranie stanu ze sklepu, zapis do katalogu pośrednika czy aktualizacja oferty marketplace. To mogą być odrębne etapy z osobnymi wynikami. Poprawny pierwszy krok nie dowodzi zakończenia następnych.

W Base dokumentacja kieruje do ustawień synchronizacji stanów konta marketplace oraz powiązań oferty z produktem. Opisuje reguły zwiększania i zmniejszania ilości, zachowanie przy zerze oraz ograniczenia zakończeń. Log może wyjaśniać pominięcie, brak powiązania lub osiągnięty limit. Źródłem jest instrukcja synchronizacji stanów Base.

Zapis operacji, który da się sprawdzić

Zanotuj czas, identyfikator produktu i oferty, wartość wysłaną, rezultat oraz komunikat błędu. Oddziel błąd API od celowego pominięcia wynikającego z reguły. Gdy oferta pozostaje aktywna przy braku towaru, sprawdź między innymi limit i powiązanie, zamiast zakładać awarię całego połączenia.

Brak produktu w źródle nie jest automatycznie wartością zero. Usunięcie rekordu może przerwać powiązanie, dlatego nie traktuj kasowania jako sposobu wyłączenia sprzedaży. Dokładne zachowanie powinno wynikać z dokumentacji danego modułu i jego ustawień.

Kod HTTP 200 może oznaczać jedynie poprawne odebranie żądania. Odczytaj treść wyniku i stan docelowy. Przy zadaniach asynchronicznych sprawdź, czy operacja została tylko przyjęta do kolejki, czy rzeczywiście zakończona.

Nie zgaduj adresu endpointu, ważności klucza ani limitu czasu. Ustal je w używanym konektorze. Zwiększenie pamięci PHP lub wymiana harmonogramu zadań bez dowodu przyczyny może niczego nie zmienić. Najpierw powiąż komunikat błędu z konkretną operacją i warunkami jej wykonania.

W WooCommerce stan produktu wariantowego może być prowadzony na poziomie rodzica, poszczególnych wariantów albo w modelu mieszanym. Rodzic nie jest więc zawsze wyłącznie informacyjny. Wariant bez własnego SKU może dziedziczyć kod rodzica. Zasady opisuje dokumentacja produktów wariantowych.

Przed diagnozą odczytaj ustawienia każdego wariantu z problematycznej grupy. Zaznacz, które korzystają ze wspólnej puli, a które mają odrębny stan. Następnie sprawdź, do jakiego rekordu zapisuje integrator. Sam poprawny identyfikator produktu nadrzędnego nie potwierdza obsługi wybranej kombinacji.

Próbka pokazująca różnicę

Na kopii przygotuj warianty współdzielące zapas oraz wariant z osobną ilością. Zapisz oczekiwany skutek wyboru każdego z nich. Sprawdź też brak dostępności i dopuszczenie zamówień oczekujących. Widoczność całej karty nie dowodzi, że konkretny rozmiar można dostarczyć.

Dla zestawu ustal listę składników, ich ilości i sposób blokowania zapasu. Jeśli ten sam składnik sprzedaje się samodzielnie i w kilku kompletach, dostępność powinna wynikać z uzgodnionej logiki. Nie dodawaj do zapasu składnika również liczby możliwych zestawów, bo może to policzyć te same sztuki ponownie.

Sprawdź anulowanie tylko części zestawu, zmianę ilości i zwrot jednego elementu. Takie operacje mogą wymagać odrębnych reguł biznesowych. Nie rozstrzygaj ich przez ręczne wpisanie liczby na karcie produktu bez powiązania z historią zamówienia.

Jeśli problem występuje wyłącznie po zmianie cech produktu, przejrzyj historię importów i mapowanie starych wariantów. Zmiana nazwy koloru nie powinna przypadkowo tworzyć nowej puli zapasu ani odłączać istniejących ofert.

W integracji ERP ustal osobno źródło stanów, rezerwacji, cen oraz dokumentów. Dostęp do systemu nie oznacza, że konektor pobiera właściwy magazyn lub interpretuje każdy dokument zgodnie z procesem firmy. Potrzebna jest mapa pól i zdarzeń, a nie ogólna deklaracja dwukierunkowej synchronizacji.

Zapytaj właściciela procesu, kiedy towar przestaje być dostępny do kolejnego zakupu. Może to być inny moment niż wystawienie dokumentu sprzedaży lub fizyczne wydanie. Jeśli rezerwacja i rozchód są przesyłane jako dwa niezależne pomniejszenia bez właściwego rozliczenia, wynik może zostać zaniżony.

Dokument nie jest dowolnym przełącznikiem

Odczytaj powiązanie zamówienia z rezerwacją, dokumentem wydania i ewentualną korektą. Nie zakładaj, że każda pro forma blokuje zapas albo każda refundacja przywraca towar do sprzedaży. Znaczenie dokumentu zależy od konfiguracji i przyjętego obiegu.

Sprawdź także przesunięcia między magazynami, towary w kontroli i zapas przypisany innemu kanałowi. Widoczna suma może być poprawna dla księgowości, ale niewłaściwa jako dostępność sklepu. W porównaniu zapisuj dokładny magazyn, pole i jednostkę.

Przy Subiekcie przydatny jest poradnik synchronizacji sklepu z Subiektem nexo. Szersze zależności danych opisuje materiał o problemach z produktami i integracją systemów. W aktualnym incydencie skup się na konkretnym zdarzeniu i dowodzie jego przetworzenia.

Korekty dokumentów oraz inwentaryzację uzgadnia właściciel procesu z odpowiednimi osobami, w tym księgowością. Skrypt synchronizacyjny nie powinien samodzielnie tworzyć dokumentów tylko po to, aby liczby na ekranach zaczęły się zgadzać.

W modelu korzystającym z zapasu dostawcy potrzebujesz daty aktualizacji źródła i informacji, co oznacza jego pole dostępności. Liczba sztuk, ogólny status oraz przewidywana dostawa to różne dane. Nie przeliczaj oznaczenia dostępny na arbitralną ilość, jeśli dostawca jej nie gwarantuje.

Zachowaj plik lub odpowiedź API użyte przy problematycznym imporcie. Sprawdź format, kompletność, jednostkę i identyfikatory. Czas pobrania nie jest tym samym co czas aktualności danych. Plik pobrany przed chwilą może zawierać starszy stan.

Trzy odmienne sytuacje

Poprawne zero oznacza brak według kontraktu danych. Pusty plik może być błędem eksportu, a niedostępny endpoint problemem połączenia. Każda sytuacja wymaga osobnej reakcji. Nie zamieniaj automatycznie wszystkich brakujących rekordów na zero i nie zachowuj bez końca starej dostępności bez sygnału ostrzegawczego.

Ustal z dostawcą znaczenie rezerwacji, moment potwierdzenia realizacji i możliwe opóźnienia. Komunikat dla kupującego powinien odpowiadać potwierdzonym warunkom. Nie wpisuj terminu wysyłki wyłącznie po to, aby ukryć niepewność feedu. Model sprzedaży omawia poradnik sklepu bez własnego magazynu.

Bufor dostępności można rozważyć na podstawie zmierzonego opóźnienia, rotacji i kosztu pomyłki. Nie istnieje jeden procent pasujący do całego asortymentu. Bufor nie daje gwarancji uniknięcia nadmiernej sprzedaży, jeśli źródło jest błędne lub kilka kanałów korzysta z tego samego zapasu.

Jeśli korzystasz z kilku dostawców, sprawdź, czy ten sam produkt nie został zdublowany i czy zamiana źródła nie zmienia terminu, wariantu lub warunków realizacji. Decyzja o alternatywnym dostawcy wymaga oceny całej oferty.

Synchronizacja uruchamiana zdarzeniem oraz okresowe pobieranie mają inne właściwości. Oba modele mogą działać poprawnie, jeżeli odpowiadają potrzebom i mają kontrolę błędów. Określenie real-time nie jest dowodem stałej aktualizacji w sekundę ani odporności na awarię sieci.

Zmierz czas od zdarzenia w źródle do potwierdzonej zmiany w kanale. Rozdziel oczekiwanie na eksport, kolejkę, wykonanie żądania i aktualizację widoku. Sprawdź różne pory oraz obciążenie, zamiast oceniać integrację po jednym udanym przebiegu.

Ponowienie bez podwójnej operacji

Timeout nie rozstrzyga, czy odbiorca wykonał zmianę. Jeśli komunikat zaginął po zapisie, ponowne odjęcie ilości może stworzyć kolejną rozbieżność. Mechanizm powinien rozpoznawać identyfikator operacji i sprawdzać jej rezultat przed ponowieniem. Szczegółowe rozwiązanie zależy od API i konektora.

Starszy komunikat nie powinien nadpisywać nowszej wersji stanu. Odtwórz sytuację, w której odpowiedzi docierają w innej kolejności niż wysłane żądania. Ustal, czy system porównuje wersję, czas zdarzenia lub inny wiarygodny znacznik. Sama kolejność odbioru może być niewystarczająca.

Przejrzyj nieudane zadania i harmonogram. Odróżnij brak uruchomienia od wielokrotnego wykonania oraz przekroczenia limitu API. Nie zwiększaj częstotliwości bez sprawdzenia limitów i obciążenia: dodatkowe żądania mogą pogłębić kolejkę zamiast skrócić opóźnienie.

Dla ostatniej sztuki sprzedawanej w kilku kanałach oceń wspólną rezerwację i moment publikacji dostępności. Lokalna blokada w jednym sklepie nie chroni automatycznie pozostałych. Test współbieżności wykonaj na syntetycznych danych i atrapach kanałów, bez prawdziwych zakupów.

Rekoncyliacja oznacza porównanie danych według wspólnej definicji i wyjaśnienie różnic. Nie polega na ustawieniu wszędzie tej samej liczby bez sprawdzenia rezerwacji. Wybierz moment odniesienia i zapisz operacje, które zaszły podczas liczenia lub eksportu, aby nie porównywać różnych stanów czasowych.

Fizyczną weryfikację i dokumentowanie różnic prowadź według procedury firmy. Właściciel magazynu powinien potwierdzić produkt, jednostkę, lokalizację i stan jakościowy towaru. Częstotliwość oraz zakres kontroli wynikają z procesu i ryzyka, nie z uniwersalnego progu liczby SKU.

Plan naprawy dla rozpoznanej przyczyny

Najpierw wskaż źródło błędu i miejsce, w którym należy je poprawić. Jeżeli przyczyną jest mapowanie, samo wyrównanie ilości w kanale nie zapobiegnie powrotowi problemu. Jeżeli źródło jest poprawne, nie nadpisuj go wartością pochodzącą z opóźnionej oferty.

Przygotuj listę rekordów, wartości przed zmianą, oczekiwany rezultat i sposób cofnięcia. Rozdziel naprawę konfiguracji od korekty istniejących danych. Ustal, które zadania mogą jeszcze czekać w kolejce i czy po wznowieniu nie odtworzą starego stanu.

Korektę wykonuje uprawniona osoba w uzgodnionym oknie, po zabezpieczeniu materiału. Zacznij od ograniczonego zakresu i sprawdź wynik u źródła oraz w kanałach. Nie usuwaj historii, aby raport wyglądał czyściej. Powinna pozwalać wyjaśnić powód zmiany i jej odpowiedzialnego.

Nie traktuj refundacji jako automatycznego przyjęcia towaru do pełnowartościowego zapasu. Zwrot może wymagać oględzin, innej lokalizacji lub decyzji o wyłączeniu ze sprzedaży. Rozliczenie finansowe i magazynowe muszą się łączyć przez konkretną sprawę, ale nie są tym samym zdarzeniem.

Kontrola powinna odtworzyć przyczynę incydentu oraz przypadki sąsiednie, które zmiana może naruszyć. Przygotuj kopię danych, syntetyczne zamówienia i atrapy płatności, marketplace, dokumentów oraz przesyłek. Zablokuj rzeczywiste wiadomości i konwersje. Test ma potwierdzić proces bez zmieniania prawdziwego zapasu.

Ustal monitoring wieku danych, nieudanych operacji, niejednoznacznych powiązań oraz rozbieżności. Alert powinien wskazywać produkt, kanał, czas i właściciela reakcji. Próg dobierz do zmierzonego działania i znaczenia problemu, zamiast kopiować procent z innego sklepu.

Do przekazania specjaliście przygotuj mapę systemów, wersje konektorów, przykładowe identyfikatory, oś czasu oraz zanonimizowane logi. Zaznacz, co potwierdzono, a co pozostaje hipotezą. Nie przesyłaj kluczy API ani pełnych danych klientów w zwykłym opisie zadania.

Koszt diagnozy zależy od liczby przepływów, dostępności dowodów i możliwości odtworzenia. Wycena powinna rozdzielać analizę, naprawę, korekty danych i późniejsze utrzymanie. Nie obiecuj terminu ani oszczędności przed ustaleniem zakresu.

Przy porządkowaniu sklepu internetowego opisz konkretną rozbieżność i jej skutki. Przez kontakt z KC Mobile możesz omówić zakres diagnostyki oraz odbioru. Gotowa naprawa powinna mieć dowód działania, właściciela monitoringu i instrukcję reakcji na powrót problemu.