Stany magazynowe w WooCommerce się nie zgadzają - ścieżka diagnostyczna

Masz na półce 12 sztuk, a sklep pokazuje 7. Albo odwrotnie: klient kupuje produkt, którego fizycznie nie ma, i zaczyna się nieprzyjemna rozmowa o zwrocie. Albo najgorszy wariant: w panelu widzisz „Na stanie: 30″, a na stronie produktu widnieje „Brak w magazynie” i tracisz sprzedaż, nie wiedząc o tym.

To nie jest jeden problem. To co najmniej dziesięć różnych problemów, które dają ten sam objaw. Poniżej znajdziesz kolejność sprawdzania, która pozwala je odsiać w rozsądnym czasie, od rzeczy zajmujących dwie minuty po te wymagające zaglądania do bazy danych.

Zanim zaczniesz: nazwij objaw precyzyjnie

Od tego zależy, w którą stronę idziesz. Rozjazdy stanów dzielą się na trzy zupełnie różne rodziny.

A. Panel pokazuje inną liczbę niż fizyczny magazyn. Sklep mówi 7, w regale leży 12. Liczba w WooCommerce jest spójna wszędzie, po prostu nieprawdziwa. Przyczyna leży w tym, co zmienia stan: zamówienia, zwroty, integracje, ręczne edycje.

B. Panel pokazuje jedną liczbę, a frontend drugą. W edycji produktu widzisz 30 sztuk, na stronie produktu „Brak w magazynie” albo produkt w ogóle nie pojawia się na liście kategorii. To problem czysto techniczny: cache albo rozjazd tabeli pomocniczej. Fizyczny magazyn nie ma tu nic do rzeczy.

C. Liczby zmieniają się „same”. Stan spada bez zamówień, rośnie bez zwrotów, albo po jednym zamówieniu spada o dwie sztuki. To znak, że coś poza normalnym przepływem WooCommerce pisze po stanach: integracja, wtyczka, import albo podwójne odliczanie.

Jeśli masz wariant B, przeskocz od razu do kroku 4 i 5. To najczęstsza przyczyna i najszybsza naprawa. Warianty A i C wymagają przejścia całej ścieżki.

Fundament: gdzie WooCommerce trzyma stan i kto go zmienia

Bez tego dalsza diagnostyka to zgadywanie.

Liczba sztuk nie leży w jednym miejscu, tylko w dwóch, i to jest źródło ogromnej części problemów:

wp_postmeta, klucz _stock. To wartość „prawdziwa”, widoczna w edycji produktu.
wp_wc_product_meta_lookup, kolumny stock_quantity i stock_status. Tabela pomocnicza, z której WooCommerce korzysta przy listowaniu produktów, filtrach i sortowaniu, bo jest szybsza. Frontend często czyta właśnie stąd.

Kiedy te dwa źródła się rozjadą, dostajesz dokładnie objaw B.

Do tego dochodzi trzecia tabela: wp_wc_reserved_stock, czyli tymczasowe rezerwacje robione w momencie wejścia klienta do kasy. Nie zmieniają one _stock, ale pomniejszają dostępność.

Kiedy stan spada: przy przejściu zamówienia w status W trakcie realizacji, Zrealizowane lub Wstrzymane. To ostatnie zaskakuje wiele osób, bo oznacza, że przelew tradycyjny blokuje towar od razu. Odpowiada za to funkcja wc_maybe_reduce_stock_levels().

Kiedy stan wraca: przy przejściu w status Anulowane lub Oczekujące na płatność.

Kiedy stan NIE wraca automatycznie:

przy statusie Nieudane (failed),
przy statusie Zwrócone (refunded),
przy zwrocie częściowym, jeśli nie zaznaczysz opcji przywrócenia towaru,
przy usunięciu zamówienia do kosza lub trwałym skasowaniu.

Zabezpieczeniem przed podwójnym odliczeniem jest metadana zamówienia _order_stock_reduced. Jeśli ma wartość yes, WooCommerce nie odejmie towaru drugi raz. Wtyczki, które wołają wc_reduce_stock_levels() po swojemu, potrafią ten mechanizm ominąć i wtedy jedno zamówienie zdejmuje towar dwukrotnie.

Krok 1: Notatki do zamówienia, czyli najszybszy trop

Zanim otworzysz phpMyAdmin, otwórz dowolne zamówienie, przy którym podejrzewasz rozjazd, i zjedź do sekcji Notatki do zamówienia w prawej kolumnie.

WooCommerce loguje tam każdą zmianę stanu w formacie:

Zmniejszono stan magazynowy przedmiotu: Koszulka XL 12→11.

To najbardziej niedoceniane narzędzie diagnostyczne w całym systemie. Czego szukasz:

Dwa wpisy o zmniejszeniu dla tej samej pozycji. Masz podwójne odliczanie, idź do kroku 10.
Brak jakiegokolwiek wpisu, mimo że zamówienie jest opłacone. Odliczanie nie zadziałało w ogóle. Zwykle wtyczka płatności nie wywołuje właściwego zdarzenia albo status przeskoczył nietypową ścieżką.
Skok niezgodny z zamówioną ilością (klient kupił 1 szt., a stan spadł o 3). Sprawdź, czy produkt nie jest zestawem i czy integracja nie nadpisała wartości w tej samej sekundzie.
Wpis „Zwiększono stan” przy zamówieniu, które nie było anulowane. Coś przywróciło towar bez powodu.

Przejrzyj kilkanaście ostatnich zamówień. Jeśli anomalia powtarza się tylko przy jednej metodzie płatności albo tylko przy zamówieniach z jednego kanału, masz już zawężony obszar.

Krok 2: Wstrzymany stan i porzucone koszyki

Klasyczny scenariusz: klient wchodzi do kasy, nie kończy płatności, znika. WooCommerce zarezerwował mu towar.

Sprawdź: WooCommerce → Ustawienia → Produkty → Stany magazynowe → Wstrzymaj stan magazynowy (minuty).

Domyślnie to 60 minut. Ta jedna wartość steruje dwiema rzeczami: jak długo trzymana jest rezerwacja w kasie oraz po jakim czasie nieopłacone zamówienie zostaje automatycznie anulowane, a towar wraca na stan.

Objawy, że tu leży problem:

produkt pokazuje mniejszą dostępność niż _stock w panelu,
masz stosy zamówień w statusie Oczekujące na płatność sprzed wielu dni,
przy niskich stanach (1 do 3 szt.) produkt regularnie „znika” i wraca.

Sprawdzenie rezerwacji w bazie:

sql

SELECT order_id, product_id, stock_quantity, `expires`
FROM wp_wc_reserved_stock
ORDER BY `expires` DESC;

Jeśli widzisz tam wiersze z datą wygaśnięcia w przeszłości, które nadal siedzą w tabeli, masz problem z cronem. Przejdź do kroku 3.

Jeśli pole „Wstrzymaj stan” jest puste, automatyczne anulowanie nieopłaconych zamówień w ogóle nie działa. Przy przelewie tradycyjnym oznacza to, że towar potrafi być zablokowany w nieskończoność przez zamówienie, którego nikt nigdy nie opłaci.

Krok 3: Cron i Action Scheduler

Bardzo dużo procesów w WooCommerce jest odroczonych: anulowanie nieopłaconych zamówień, czyszczenie rezerwacji, synchronizacje, przeliczenia. Wszystkie zależą od tego, czy zadania w tle się wykonują.

Wejdź w WooCommerce → Status → Zaplanowane działania.

Na co patrzeć:

Zakładka Oczekujące. Jeśli liczba idzie w tysiące i są tam wpisy sprzed kilku dni, kolejka jest zapchana.
Zakładka Nieudane. Powtarzające się błędy przy jednym typie zadania wskazują konkretną wtyczkę.
Szukaj zadania woocommerce_cancel_unpaid_orders. Jeśli nie ma go w harmonogramie albo od dawna nie zostało wykonane, potwierdza to diagnozę z kroku 2.

Przyczyny zapchanej kolejki to zwykle wyłączony wp-cron bez skonfigurowania crona systemowego, hosting agresywnie ubijający długie procesy PHP albo po prostu za mały limit pamięci.

Rozwiązanie docelowe. Wyłącz pseudo-cron i podepnij prawdziwy cron systemowy co kilka minut:

php

// wp-config.php
define( 'DISABLE_WP_CRON', true );

bash

*/5 * * * * curl -s https://twojsklep.pl/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Jeśli nie masz pewności, czy zadania w tle na Twoim sklepie w ogóle działają, warto zajrzeć też do wpisu o sklepie, który nie wysyła maili z potwierdzeniem. To często ten sam pierwotny problem dający dwa różne objawy.

Krok 4: Rozjazd tabeli lookup, czyli panel kontra frontend

To jest rozwiązanie objawu B i naprawdę częsta sprawa po migracjach, masowych importach i nieudanych aktualizacjach.

Diagnoza SQL pokazuje produkty, w których wartość „prawdziwa” różni się od tej używanej przez frontend:

sql

SELECT p.ID,
       p.post_title,
       CAST(pm.meta_value AS SIGNED) AS meta_stock,
       l.stock_quantity              AS lookup_stock,
       l.stock_status
FROM wp_posts p
JOIN wp_postmeta pm
     ON pm.post_id = p.ID AND pm.meta_key = '_stock'
JOIN wp_wc_product_meta_lookup l
     ON l.product_id = p.ID
WHERE CAST(pm.meta_value AS SIGNED) <> l.stock_quantity;

Pusty wynik oznacza, że tabela jest spójna. Idź dalej. Kilkadziesiąt wierszy oznacza, że znalazłeś przyczynę.

Naprawa: WooCommerce → Status → Narzędzia → Zregeneruj tabele wyszukiwania produktów. Na dużym katalogu, rzędu kilkunastu tysięcy SKU, uruchom to poza godzinami szczytu. Zadanie idzie przez Action Scheduler i potrafi trwać.

Z linii poleceń:

bash

wp wc tool run regenerate_product_lookup_tables --user=1
wp action-scheduler run

Krok 5: Cache na czterech poziomach

Jeśli po regeneracji tabeli frontend nadal kłamie, to warstwa cache.

Sprawdź po kolei, od najbardziej zewnętrznej:

Cache CDN lub Cloudflare. Strona produktu serwowana z krawędzi sieci sprzed godziny. Wyczyść i sprawdź w trybie prywatnym.
Full page cache (LiteSpeed, WP Rocket, WP Super Cache). Upewnij się, że strony koszyka, kasy i konta są wykluczone z cache’owania. Przy niskich stanach warto wykluczyć też strony produktów z ograniczoną dostępnością.
Object cache (Redis, Memcached). Trzyma obiekty produktów. Po ręcznej zmianie stanu w bazie, na przykład przez SQL, obiekt w cache pozostaje stary.
Transienty WooCommerce. WooCommerce → Status → Narzędzia → Wyczyść dane przejściowe produktów.

Szybki test rozstrzygający: otwórz stronę produktu w trybie incognito, dopisując do adresu losowy parametr, na przykład ?test=1234. Jeśli teraz stan jest poprawny, to cache, nie baza.

Przy okazji: jeśli sklep ogólnie działa wolno i nawarstwiłeś kilka warstw cache, żeby to zamaskować, warto wrócić do przyczyn wolnego działania WooCommerce. Agresywne cache’owanie sklepu to leczenie objawu.

Krok 6: Zwroty, anulacje i zamówienia w koszu

Tu wycieka najwięcej stanu w sklepach, które „w zasadzie działają dobrze”.

Zwrot nie przywraca towaru automatycznie. Kiedy w zamówieniu klikasz Zwrot, w oknie pojawia się przełącznik „Uzupełnij zwrócone przedmioty”. Jest domyślnie włączony, ale wystarczy, że ktoś z obsługi go raz odznaczy albo wpisze kwotę zwrotu bez ilości pozycji, a towar fizycznie wraca na półkę, podczas gdy w systemie nie.

Zwrot kwotowy bez pozycji. Jeśli wpisujesz tylko kwotę w polu „Kwota zwrotu”, bez uzupełnienia ilości przy pozycjach, WooCommerce nie ma pojęcia, jaki produkt wrócił. Stan się nie zmieni.

Status „Zwrócone” ustawiony ręcznie. Ręczna zmiana statusu zamówienia na Zwrócone nie przywraca stanu. Robi to tylko realny zwrot przez przycisk Zwrot.

Kosz. Przeniesienie zamówienia do kosza nie jest niezawodnym sposobem na oddanie towaru. Jeśli anulujesz zamówienie, zmień jego status na Anulowane. Dopiero wtedy zadziała wc_maybe_increase_stock_levels().

Praktyczny audyt: przejrzyj zamówienia z ostatnich 30 dni w statusie Zwrócone i Nieudane i porównaj z notatkami. Zamówienia nieudane, przy których wcześniej doszło do odliczenia, bo na przykład przeszły przez status Wstrzymane, to czysta strata stanu.

Krok 7: Warianty produktów

Produkty wariantowe mają własną, osobną logikę i generują nieproporcjonalnie dużo zgłoszeń.

Zasady, które trzeba znać:

Wariant może mieć własne zarządzanie stanem, wtedy liczy się jego _stock, albo dziedziczyć po rodzicu, wtedy liczy się pula wspólna.
Rodzic może mieć ustawiony stock_status na Brak w magazynie niezależnie od tego, co mają warianty. Skutek: produkt jest niedostępny, choć każdy wariant ma stan.
Odwrotnie: rodzic „Na stanie”, ale wszystkie warianty wyzerowane. Produkt wyświetla się na listingach, a przy wyborze rozmiaru klient dostaje komunikat o niedostępności.

Sprawdzenie: wejdź w produkt, zakładka Warianty, rozwiń każdy wariant i zweryfikuj checkbox „Zarządzaj stanem magazynowym”. Potem wróć do zakładki Magazyn na poziomie rodzica i sprawdź, czy tam też nie jest włączone zarządzanie. Jeśli oba poziomy mają je włączone, masz dwa niezależne liczniki i gwarantowany rozjazd.

Krok 8: Integracje zewnętrzne, najczęstsza przyczyna w polskich sklepach

Jeśli sklep jest podpięty do BaseLinkera, Subiekta, wFirmy, Allegro, hurtowni dropshippingowej albo dowolnego ERP-a, zacznij podejrzenia właśnie tutaj.

Problem numer jeden: dwa źródła prawdy. WooCommerce zmniejsza stan przez odejmowanie (stan = stan - 1). ERP zwykle wysyła wartość bezwzględną (ustaw stan = 42). Kiedy obie operacje zachodzą blisko siebie, jedna nadpisuje drugą. Klasyczny „lost update”: ERP odczytał 42, w międzyczasie wpadło zamówienie i stan zszedł do 41, ERP zapisuje swoje 42, więc sprzedana sztuka wróciła na stan z powietrza.

Dokładnie odwrotny scenariusz też występuje i wtedy sprzedajesz towar, którego nie masz.

Rozwiązanie: wybierz jedno źródło prawdy i wyłącz synchronizację w drugą stronę. Jeżeli magazynem rządzi ERP, WooCommerce ma tylko przyjmować wartości i nigdy ich nie odsyłać. Jeżeli rządzi WooCommerce, ERP nie nadpisuje stanów.

Problem numer dwa: interwał synchronizacji. Synchronizacja co 15 minut przy sprzedaży wielokanałowej to okno, w którym Allegro i sklep mogą sprzedać tę samą ostatnią sztukę. Przy niskich stanach warto trzymać bufor bezpieczeństwa i nie wystawiać ostatniej sztuki w kanale zewnętrznym. Jeśli dopiero układasz ten proces, przyda się wpis o integracji WooCommerce z Allegro.

Problem numer trzy: mapowanie po SKU. Integracje dopasowują produkty po symbolu. Zduplikowane lub puste SKU to gwarancja, że stan trafi nie tam, gdzie powinien.

Znajdź duplikaty:

sql

SELECT meta_value AS sku, COUNT(*) AS ile
FROM wp_postmeta
WHERE meta_key = '_sku' AND meta_value <> ''
GROUP BY meta_value
HAVING ile > 1;

Problem numer cztery: zamówienia spoza sklepu. Sprzedaż w sklepie stacjonarnym, telefoniczna, przez Messengera. Jeśli nie trafia do systemu, żadna diagnostyka techniczna nie pomoże. Rozjazd jest realny i proceduralny.

Krok 9: Importy CSV i masowa edycja

Import to najszybszy sposób na zniszczenie stanów w całym katalogu.

Kolumna Stock pozostawiona pusta przy zaznaczonej opcji „Zaktualizuj istniejące produkty” potrafi wyzerować stany, zamiast je pominąć.
Niedopasowane SKU tworzą duplikaty produktów zamiast aktualizować istniejące. W katalogu masz nagle dwa razy ten sam towar, każdy z własnym stanem.
Szybka edycja i Edycja masowa na liście produktów nadpisują wartość w momencie kliknięcia. Jeśli w tym czasie wpadło zamówienie, jego efekt zostaje wymazany.

Zasada: każdy import stanów robimy najpierw na kopii sklepu, a przed importem na produkcji wykonujemy kopię zapasową bazy. Bez wyjątków.

Krok 10: Podwójne odliczanie

Objaw: jedno zamówienie na 1 sztukę zdejmuje 2 sztuki. W notatkach zamówienia widać dwa wpisy o zmniejszeniu.

Przyczyna prawie zawsze leży we wtyczce, która wywołuje wc_reduce_stock_levels() samodzielnie, ignorując flagę _order_stock_reduced. Najczęściej robią to niestandardowe bramki płatności, wtyczki do faktur, integracje kurierskie i customowe rozwiązania „dopisane przez poprzedniego programistę”.

Sprawdzenie flagi na sklepie z HPOS, czyli nowym magazynem zamówień:

sql

SELECT order_id, meta_value
FROM wp_wc_orders_meta
WHERE meta_key = '_order_stock_reduced';

Na starszym magazynie zamówień:

sql

SELECT post_id, meta_value
FROM wp_postmeta
WHERE meta_key = '_order_stock_reduced';

Test rozstrzygający: wyłącz wtyczki po kolei, zaczynając od płatności i integracji, po każdej złóż zamówienie testowe za 1 grosz i sprawdź notatki. Rób to na kopii sklepu, nie na produkcji.

Narzędzie ostateczne: log każdej zmiany stanu

Kiedy przeszedłeś całą ścieżkę i nadal nie wiesz, co rusza liczbami, przestań zgadywać i zacznij logować. Poniższy fragment zapisuje każdą zmianę stanu razem ze śladem wykonania, czyli listą funkcji, które do niej doprowadziły. To praktycznie wskazuje palcem winną wtyczkę.

Wklej go do pliku functions.php motywu potomnego lub, lepiej, do własnej wtyczki mu-plugin:

php

<?php
/**
 * Audyt zmian stanów magazynowych.
 * Logi: WooCommerce → Status → Logi, źródło "audyt-stanow".
 */
add_action( 'woocommerce_product_set_stock', 'cbz_loguj_zmiane_stanu' );
add_action( 'woocommerce_variation_set_stock', 'cbz_loguj_zmiane_stanu' );

function cbz_loguj_zmiane_stanu( $product ) {

    $slad = wp_debug_backtrace_summary( null, 0, false );
    $slad = is_array( $slad )
        ? implode( ' <- ', array_slice( $slad, 0, 12 ) )
        : (string) $slad;

    if ( defined( 'DOING_CRON' ) && DOING_CRON ) {
        $zrodlo = 'CRON';
    } elseif ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
        $zrodlo = 'REST API';
    } else {
        $zrodlo = $_SERVER['REQUEST_URI'] ?? 'CLI';
    }

    wc_get_logger()->info(
        sprintf(
            "ID %d | %s | nowy stan: %s | user: %d | zrodlo: %s\nSlad: %s",
            $product->get_id(),
            $product->get_name(),
            var_export( $product->get_stock_quantity(), true ),
            get_current_user_id(),
            $zrodlo,
            $slad
        ),
        [ 'source' => 'audyt-stanow' ]
    );
}

Zostaw to na 24 do 48 godzin normalnego ruchu, potem wejdź w WooCommerce → Status → Logi i wybierz źródło audyt-stanow. W śladzie wykonania zobaczysz nazwy plików. Jeśli powtarza się ścieżka z katalogu konkretnej wtyczki, masz sprawcę.

Po zakończeniu diagnostyki usuń ten kod. Na sklepie z dużym ruchem generuje spore pliki logów.

Trzy ustawienia, które udają awarię

Zanim uznasz, że coś jest zepsute, sprawdź WooCommerce → Ustawienia → Produkty → Stany magazynowe.

„Próg braku w magazynie” ma domyślnie wartość 0. Jeśli ktoś ustawił tam 2, produkt z dwiema sztukami będzie oznaczony jako niedostępny. Wszystko działa zgodnie z konfiguracją, tylko nikt o niej nie pamięta.

„Ukryj produkty niedostępne w magazynie” sprawia, że produkty nie znikają z bazy, ale znikają z listingów i wyników wyszukiwania. Klient wchodzący z Google na stary link dostaje stronę produktu, ale nie znajdzie go w kategorii.

„Zezwalaj na zamówienia oczekujące” przy ustawieniu Zezwól pozwala stanowi zejść poniżej zera. Wartość -8 w panelu nie jest błędem, tylko informacją, że masz osiem sztuk długu wobec klientów.

Kolejność naprawy, wersja skrócona

Kiedy trzeba działać szybko:

Kopia zapasowa bazy danych. Przed czymkolwiek.
Notatki przy 10 do 20 ostatnich zamówieniach. Szukaj dubli i braków.
WooCommerce → Status → Narzędzia → Wyczyść dane przejściowe produktów.
WooCommerce → Status → Narzędzia → Zregeneruj tabele wyszukiwania produktów.
Wyczyść cache stron, object cache i CDN.
WooCommerce → Status → Zaplanowane działania. Sprawdź zaległości i błędy.
Sprawdź ustawienie „Wstrzymaj stan magazynowy” i zamówienia oczekujące starsze niż doba.
Zatrzymaj synchronizację z ERP lub BaseLinkerem na czas diagnozy.
Zrób ręczną inwentaryzację 20 najlepiej sprzedających się SKU i wprowadź prawdziwe wartości.
Włącz log audytu i obserwuj przez dobę.

Jak zapobiegać na stałe

Jedno źródło prawdy. Zdecyduj, czy magazynem rządzi WooCommerce, czy system zewnętrzny. Dwukierunkowa synchronizacja stanów bez mechanizmu rozstrzygania konfliktów zawsze się w końcu rozjedzie.

Prawdziwy cron systemowy. Pseudo-cron zależny od ruchu na stronie to za mało dla sklepu, w którym rezerwacje i anulacje muszą działać punktualnie.

Unikalne, niepuste SKU. Traktuj to jak wymóg twardy, nie dobrą praktykę.

Bufor przy sprzedaży wielokanałowej. Nie wystawiaj ostatniej sztuki jednocześnie w sklepie i na Allegro.

Procedura zwrotów. Obsługa musi wiedzieć, że zwrot robi się przyciskiem Zwrot z uzupełnionymi ilościami, a nie ręczną zmianą statusu.

Cykliczna kontrola. Raz w miesiącu porównaj stany 20 do 30 najczęściej rotujących SKU z fizycznym magazynem. Znajdziesz wyciek, zanim urośnie.

Środowisko testowe. Aktualizacje WooCommerce, motywu i wtyczek integracyjnych najpierw na kopii. Rozjazdy stanów bardzo często zaczynają się dzień po aktualizacji zrobionej „na żywo”.

Najczęstsze pytania

Czy anulowanie zamówienia przywraca towar? Tak, przy zmianie statusu na Anulowane lub Oczekujące na płatność. Przeniesienie zamówienia do kosza nie.

Dlaczego stan spadł, chociaż klient nie zapłacił? Bo zamówienie przeszło przez status Wstrzymane. Ten status blokuje towar. Przy przelewie tradycyjnym to zachowanie domyślne i zwykle pożądane, pod warunkiem że działa automatyczne anulowanie nieopłaconych zamówień.

Mam ujemny stan magazynowy. To błąd? Nie, jeśli masz włączone zamówienia oczekujące. Tak, jeśli ich nie masz. Wtedy oznacza to podwójne odliczanie lub nadpisanie przez integrację.

Czy da się odzyskać prawidłowe stany po tym, jak integracja je nadpisała? Tylko z kopii zapasowej sprzed zdarzenia albo przez odtworzenie z historii zamówień i dokumentów przyjęć. WooCommerce nie prowadzi wersjonowania stanów. To główny argument za codziennym backupem bazy.

Czy regeneracja tabel wyszukiwania jest bezpieczna? Tak. Przelicza tabelę pomocniczą na podstawie danych źródłowych, nie zmienia samych produktów. Na dużych katalogach potrafi jednak mocno obciążyć serwer, więc uruchamiaj ją poza szczytem.

Kiedy oddać to komuś

Ścieżka powyżej rozwiązuje większość przypadków. Warto poszukać pomocy, jeśli:

rozjazd występuje mimo wyłączonych integracji i wyczyszczonego cache,
log audytu pokazuje zmiany bez śladu wykonania albo z niestandardowego kodu,
sklep sprzedaje w kilku kanałach i potrzebujesz przeprojektowania przepływu danych, a nie doraźnej łatki,
straty ze sprzedaży towaru, którego nie ma, są już większe niż koszt naprawy.

Zajmuje się diagnostyką i naprawą sklepów WooCommerce, od pojedynczych awarii po uporządkowanie synchronizacji z systemami magazynowymi. Jeśli stany rozjeżdżają się u Ciebie od tygodni i nie wiadomo dlaczego, napisz. Zwykle wystarczy dostęp do panelu i doba obserwacji, żeby wskazać źródło.

Stany magazynowe w WooCommerce się nie zgadzają – ścieżka diagnostyczna