Aktualizacja WooCommerce, motywu albo jednej z wtyczek może ujawnić problem, którego wcześniej nie było widać. Cena produktu w katalogu wygląda prawidłowo, ale po dodaniu do koszyka zmienia się o wartość podatku. Innym razem klient widzi cenę netto, chociaż sklep powinien prezentować kwoty brutto, albo operator płatności odrzuca transakcję z powodu niezgodności sumy zamówienia.
W takiej sytuacji nie warto od razu przywracać całej strony z kopii zapasowej ani losowo wyłączać rozszerzeń na działającym sklepie. Skuteczna naprawa WordPress WooCommerce wymaga ustalenia, na którym etapie powstaje rozbieżność: podczas pobierania ceny produktu, obliczania podatku, budowania koszyka, tworzenia zamówienia czy przekazywania kwoty do zewnętrznej usługi.
Jak rozpoznać, z jakim błędem mamy do czynienia?
Określenie „zły VAT” może opisywać kilka niezależnych usterek. Przed rozpoczęciem diagnostyki trzeba zapisać konkretny scenariusz i oczekiwany wynik. Najczęściej występują następujące objawy:
- katalog produktów pokazuje ceny netto, a koszyk lub podsumowanie zamówienia wyświetla ceny brutto;
- podatek jest doliczany do kwoty, która już zawiera VAT;
- cena zmienia się po wpisaniu adresu dostawy albo wybraniu kraju;
- wartość jednej sztuki jest prawidłowa, ale przy większej liczbie produktów pojawia się różnica jednego lub kilku groszy;
- produkt prosty ma poprawną cenę, natomiast wariant produktu otrzymuje inną stawkę lub sposób prezentacji;
- kwota na stronie płatności różni się od sumy widocznej w WooCommerce;
- zamówienie w panelu jest prawidłowe, ale faktura lub dokument przesłany do ERP zawiera inną wartość netto albo VAT;
- administrator widzi poprawne ceny, a niezalogowany klient otrzymuje stare lub błędne dane.
Te różnice pomagają zawęzić obszar poszukiwań. Jeżeli błąd widać już na karcie produktu, należy sprawdzić ustawienia wyświetlania, motyw, cache i filtry modyfikujące cenę. Jeśli pojawia się dopiero w koszyku, podejrzenie pada między innymi na reguły rabatowe, geolokalizację, klasy podatkowe i kod przeliczający pozycje koszyka. Rozbieżność występująca wyłącznie na fakturze wskazuje natomiast na etap generowania dokumentu lub eksportu danych.
Dlaczego aktualizacja może ujawnić konflikt?
Aktualizacja nie musi sama wprowadzać błędnej stawki podatku. Często zmienia warunki, w których działa starszy kod. Rozszerzenie może korzystać z nieaktualnej metody, oczekiwać innego formatu danych albo modyfikować cenę w momencie, w którym WooCommerce przeprowadza już własne obliczenia.
Znaczenie ma również kolejność wykonywania filtrów i akcji. Dwie wtyczki mogą osobno działać poprawnie, lecz jednocześnie ingerować w tę samą wartość. Przykładowo moduł cen dla klientów biznesowych usuwa podatek, a rozszerzenie fakturowe ponownie przelicza kwotę na podstawie własnych ustawień. Po zmianie jednego elementu integracji podatek może zostać odjęty lub dodany dwukrotnie.
Źródłem problemu bywa też motyw zawierający własne szablony WooCommerce albo fragmenty kodu dodane kilka lat wcześniej do pliku functions.php. Aktualizacja może sprawić, że takie nadpisanie nadal się uruchamia, ale pracuje na danych o innym znaczeniu niż wcześniej. Osobną kategorię stanowi cache: klient widzi wtedy nie bieżące obliczenie, lecz wcześniej zapisaną wersję strony przygotowaną dla innej sesji lub lokalizacji.
Najpierw zabezpiecz sklep i zbierz dowody
Przed wprowadzaniem zmian należy wykonać kopię plików oraz bazy danych. Trzeba także zapisać wersje aktywnego motywu, WooCommerce i rozszerzeń związanych z cenami, podatkami, rabatami, fakturami, płatnościami oraz synchronizacją produktów. Przydatny jest raport stanu systemu WooCommerce, zrzuty ekranów i identyfikatory przykładowych zamówień.
Warto przygotować tabelę porównawczą dla kilku produktów. Powinna zawierać cenę wpisaną w panelu, klasę podatkową, kwotę w katalogu, koszyku, zamówieniu, bramce płatniczej, fakturze i ERP. Dzięki temu zamiast ogólnego zgłoszenia „VAT się nie zgadza” otrzymujemy dokładną informację, gdzie po raz pierwszy pojawia się różnica.
Diagnostyka tylko na kopii testowej
Wyłączanie rozszerzeń na działającym sklepie może przerwać płatność, synchronizację stanów magazynowych lub obsługę bieżącego zamówienia. Dlatego testy należy przeprowadzać na środowisku stagingowym, czyli możliwie wiernej kopii serwisu produkcyjnego.
Po skopiowaniu sklepu trzeba zabezpieczyć środowisko przed przypadkowym użyciem:
- zablokować indeksowanie i publiczny dostęp do kopii;
- wyłączyć wysyłkę prawdziwych wiadomości do klientów;
- przełączyć płatności na tryb testowy albo całkowicie je odłączyć;
- zatrzymać eksport faktur, zamówień i stanów magazynowych do systemu produkcyjnego;
- wyłączyć webhooki prowadzące do zewnętrznych usług lub podmienić ich adresy;
- sprawdzić, czy zadania cykliczne nie wykonają rzeczywistej synchronizacji.
Na kopii można włączyć rejestrowanie błędów WordPress. Komunikaty powinny trafiać do dziennika, a nie być wyświetlane klientowi na stronie. Logowanie warto uruchomić tylko na czas diagnostyki i zabezpieczyć pliki zawierające dane techniczne.
Kontrola podstawowych ustawień podatków
Zanim zaczniemy szukać konfliktu, należy wykluczyć zwykłą zmianę konfiguracji. W ustawieniach ogólnych WooCommerce sprawdzamy adres sklepu, włączenie obliczania podatków oraz domyślną lokalizację klienta. Następnie przechodzimy do ustawień podatkowych i kontrolujemy cztery powiązane obszary.
1. Sposób wprowadzania cen
Ustawienie określa, czy wartości zapisane przy produktach zawierają podatek. Jeżeli katalog został zbudowany z cen brutto, a sklep zacznie traktować je jako netto, VAT zostanie dodany ponownie. Odwrotna zmiana może spowodować obniżenie prezentowanych kwot.
2. Prezentacja cen w sklepie i koszyku
Osobne opcje odpowiadają za sposób wyświetlania cen w katalogu oraz podczas składania zamówienia. Ich niespójność może sprawić, że klient zobaczy inną kwotę przed i po dodaniu produktu do koszyka. Trzeba rozróżnić zmianę samej prezentacji od rzeczywistej zmiany wartości zamówienia.
3. Klasy i stawki podatkowe
Sprawdzamy klasę przypisaną do produktu oraz wariantów. Należy również zweryfikować tabelę stawek, zakres krajów i regionów, priorytet oraz ustawienia podatku dla wysyłki. Test powinien objąć produkt ze standardową klasą, produkt z klasą dodatkową i przynajmniej jeden wariant.
4. Zaokrąglenia
WooCommerce może zaokrąglać podatek dla poszczególnych pozycji albo na poziomie sumy. Różnica ujawnia się szczególnie przy kilku sztukach, rabatach procentowych i cenach zawierających podatek. Nie należy jednak maskować większego błędu zmianą sposobu zaokrąglania. Jeśli rozbieżność odpowiada pełnej wartości VAT, przyczyną jest raczej konfiguracja lub podwójne przeliczenie.
Geolokalizacja i cache mogą pokazywać różne ceny
Jeżeli podatek zależy od lokalizacji klienta, cena przed podaniem adresu może być obliczana na podstawie domyślnego położenia. Po uzupełnieniu kraju dostawy WooCommerce przelicza koszyk zgodnie z właściwą regułą. Sam fakt zmiany ceny nie musi więc oznaczać usterki, ale jej wynik powinien odpowiadać konfiguracji sklepu.
Problem pojawia się, gdy geolokalizacja działa nieprawidłowo albo pamięć podręczna serwuje wszystkim użytkownikom tę samą wersję strony. Koszyk, finalizacja zamówienia i konto klienta powinny pozostać dynamiczne. Podczas testów należy wyczyścić cache wtyczki, serwera, CDN i przeglądarki, a następnie powtórzyć scenariusz w nowej sesji.
Jak znaleźć wtyczkę powodującą konflikt?
Najskuteczniejsza metoda jest prosta, choć wymaga konsekwencji. Na kopii testowej przełączamy motyw na standardowy, pozostawiamy aktywny WooCommerce i wyłączamy dodatki niezwiązane bezpośrednio z testem. Następnie odtwarzamy dokładnie ten sam przypadek: ten sam produkt, liczba sztuk, adres, rabat, dostawa i metoda płatności.
Jeżeli ceny wróciły do normy, rozszerzenia włączamy pojedynczo, po każdym wykonując nowe zamówienie. Przy dużej liczbie wtyczek można najpierw aktywować je grupami, a później zawęzić test do podejrzanego zestawu. Szczególną uwagę warto poświęcić modułom:
- fakturowania i korekt;
- cen hurtowych, grup klientów i sprzedaży B2B;
- rabatów, punktów, abonamentów i pakietów produktów;
- płatności oraz płatności odroczonych;
- wielu walut i automatycznego przeliczania cen;
- integracji z ERP, magazynem, marketplace i programem księgowym;
- automatycznego obliczania podatków;
- cache i optymalizacji koszyka.
W przypadku bramki płatniczej należy porównać kwotę zamówienia zapisaną w WooCommerce z wartością wysłaną do operatora. Wtyczka płatnicza nie zawsze jest źródłem błędu. Może jedynie wykryć, że inny moduł zmienił koszyk już po utworzeniu żądania płatności. Pomocne są dzienniki dostępne w sekcji statusu WooCommerce oraz logi samego operatora.
Faktura i ERP: sprawdź, kto jest właścicielem ceny
Integracja z systemem zewnętrznym może jedynie odbierać dane z WooCommerce albo zarządzać produktami i nadpisywać ich wartości. To podstawowe rozróżnienie diagnostyczne. Jeśli ERP jest źródłem cen, ręczna poprawka w panelu sklepu może zniknąć przy kolejnym imporcie.
Trzeba sprawdzić, czy przesyłana jest cena netto, brutto, stawka podatku, kwota podatku czy wszystkie te dane jednocześnie. Dwa systemy nie powinny niezależnie obliczać tego samego elementu bez jasno ustalonych zasad. Warto również przejrzeć mapowanie klas podatkowych, walutę, liczbę miejsc dziesiętnych i kolejność synchronizacji.
Jeżeli zamówienie w WooCommerce jest poprawne, a błąd występuje wyłącznie na dokumencie, nie należy zmieniać globalnej konfiguracji podatków sklepu. Naprawy wymaga wtedy sposób, w jaki wtyczka fakturowa interpretuje pozycje zamówienia.
Motyw i własny kod ingerujący w ceny
Gdy problem znika po zmianie motywu, trzeba przejrzeć nadpisane szablony WooCommerce oraz własne funkcje. Podejrzane są fragmenty korzystające z filtrów cen produktów, zmieniające HTML ceny, modyfikujące zawartość koszyka albo ręcznie dodające i odejmujące podatek.
Do obliczeń należy wykorzystywać mechanizmy WooCommerce uwzględniające ustawienia sklepu i kontekst wyświetlania. Ręczne mnożenie ceny przez stały współczynnik jest kruche: nie bierze pod uwagę klas podatkowych, lokalizacji, cen już zawierających podatek ani szczególnych reguł produktu.
Poprawki nie powinny trafiać bezpośrednio do plików motywu lub wtyczki producenta, ponieważ kolejna aktualizacja je usunie. Bezpieczniejszym miejscem jest motyw potomny albo własna, niewielka wtyczka z udokumentowanym zakresem działania i testami.
Test zamówienia przed przywróceniem sprzedaży
Usunięcie błędu dla jednego produktu nie kończy pracy. Przed wdrożeniem poprawki trzeba wykonać zestaw kontrolnych zamówień obejmujący:
- gościa i zalogowanego klienta;
- produkt prosty oraz wariantowy;
- jedną i kilka sztuk produktu;
- różne klasy podatkowe używane w sklepie;
- kupon kwotowy i procentowy, jeżeli są stosowane;
- dostawę opodatkowaną zgodnie z konfiguracją sklepu;
- co najmniej dwie metody płatności;
- adres krajowy i zagraniczny, jeśli sklep prowadzi taką sprzedaż;
- wygenerowanie faktury, zwrot oraz eksport do ERP.
Dla każdego przypadku porównujemy katalog, koszyk, finalizację, zapisane zamówienie, płatność i dokument sprzedaży. Po wdrożeniu poprawki na produkcji należy ponownie wyczyścić pamięć podręczną i przeprowadzić krótkie zamówienie kontrolne. Warto też przez pewien czas obserwować logi oraz pierwsze rzeczywiste transakcje.
Najważniejsza jest przyczyna, nie doraźne ukrycie objawu
Zła cena po aktualizacji może wynikać z ustawień podatku, geolokalizacji, cache, konfliktu rozszerzeń, błędnego mapowania ERP albo przestarzałego kodu w motywie. Próba skorygowania końcowej kwoty kolejną funkcją często prowadzi tylko do następnego podwójnego przeliczenia.
Profesjonalna naprawa WooCommerce polega na odtworzeniu błędu na kopii, ustaleniu pierwszego miejsca powstawania rozbieżności, usunięciu konfliktu i sprawdzeniu całej ścieżki zamówienia. Takie podejście ogranicza ryzyko przerwy w sprzedaży i pozwala bezpiecznie rozwijać sklep przy kolejnych aktualizacjach.
