Programista WooCommerce w Warszawie

#WooCommerce dla warszawskich hurtowni i sklepów B2B

Warszawa jest w Polsce nie tylko rynkiem detalicznym, ale przede wszystkim węzłem dystrybucji. Wokół stolicy, przy trasach S8, S7 i A2, ciągnie się pas magazynów i centrów logistycznych od Piaseczna i Janek po Marki, Błonie i Sochaczew, a w nich siedzą hurtownie, importerzy i dystrybutorzy obsługujący klientów w całym kraju. Ci klienci coraz częściej chcą zamawiać jak w sklepie internetowym, tylko na swoich warunkach: po swoich cenach kontraktowych, na firmę, z fakturą i z płatnością odroczoną. Dokładnie w tym punkcie zwykły sklep na gotowym motywie przestaje wystarczać i zaczyna się praca programisty WooCommerce.

Ta strona jest o handlu B2B i o sklepach, które muszą się spiąć z resztą firmy, a nie tylko ładnie wyglądać. Budujemy i rozwijamy sklepy WooCommerce dla warszawskich hurtowni, marek sprzedających bezpośrednio do klienta oraz sklepów z katalogami liczonymi w tysiącach indeksów. Łączy je to, że sklep jest tylko jednym z ogniw: obok niego stoi system handlowy, magazyn, księgowość i polska bramka płatności, a WooCommerce ma się z nimi rozmawiać bez ręcznego przepisywania danych.

#Ceny per klient i rabaty kontraktowe

Model cenowy jest w handlu B2B rdzeniem projektu, a nie dodatkiem. WooCommerce w wersji podstawowej zakłada jedną cenę widoczną dla każdego, tymczasem hurtownia prowadzi tyle cenników, ilu ma większych kontrahentów. Budujemy więc warstwę, w której cena zależy od tego, kto jest zalogowany: kontrahent widzi swoje ceny netto, swoje progi ilościowe i swój rabat wynegocjowany w umowie, a przypadkowy gość albo widzi ceny detaliczne, albo nie widzi ich wcale, jeśli firma tak zdecyduje.

Progi ilościowe i rabaty kontraktowe to logika, którą projektujemy świadomie, bo łatwo tu o pułapkę. Rabat na poziomie produktu, rabat na poziomie grupy towarowej i rabat ogólny dla kontrahenta potrafią się nakładać i dawać ceny, których nikt nie zaplanował. Ustalamy więc jednoznaczną kolejność naliczania i testujemy ją na realnych koszykach, zanim cokolwiek trafi na produkcję. Jeżeli cennik kontraktowy żyje już w systemie ERP, to ERP zostaje jego jedynym źródłem prawdy, a sklep tylko go odzwierciedla, żeby handlowiec i strona internetowa nie pokazywały klientowi dwóch różnych liczb.

#Zamówienia na firmę: NIP, limity kupieckie i dokumenty

Zakup B2B to zakup na firmę, więc checkout musi to rozumieć od pierwszego pola. Formularz zamówienia zbiera NIP i dane do faktury, a przy sprzedaży wewnątrzunijnej weryfikuje numer VAT w systemie VIES, żeby poprawnie zdecydować o stawce i o mechanizmie odwrotnego obciążenia. To nie jest kosmetyka: błędna stawka VAT na fakturze hurtowej to problem księgowy, który wraca ze zdwojoną siłą przy kontroli.

Dla stałych kontrahentów wdrażamy płatność odroczoną i limit kupiecki. Klient z przyznanym limitem składa zamówienie na przelew z terminem, sklep pilnuje, żeby suma nierozliczonych zamówień nie przekroczyła ustalonego pułapu, a przekroczenie kieruje zamówienie do akceptacji handlowca zamiast je blokować bez wyjaśnienia. Po stronie dokumentów sklep nie zastępuje księgowości, tylko ją zasila: przekazuje komplet danych potrzebny do faktury i do pliku JPK, a wystawienie dokumentu, łącznie z wysyłką do KSeF, realizuje system fakturujący albo ERP. Rolą WooCommerce jest dostarczyć dane czyste i kompletne, bo brak jednego pola potrafi zatrzymać cały łańcuch dokumentów.

#Integracja z ERP i systemami magazynowymi

Najwięcej dedykowanej pracy w warszawskich projektach B2B dotyczy nie wyglądu, tylko spięcia sklepu z systemem handlowym. Integrujemy WooCommerce z Comarch ERP XL i Optima oraz z Subiektem GT i nexo, bo to na nich pracuje większość polskich hurtowni i firm handlowych. Integracja jest dwukierunkowa: z ERP do sklepu płyną cenniki, stany magazynowe i kartoteki towarowe, a ze sklepu do ERP wracają zamówienia i dane kontrahentów, gotowe do realizacji przez magazyn.

Diabeł, jak zawsze, siedzi w szczegółach synchronizacji. Ustalamy jej częstotliwość osobno dla różnych danych, bo stany magazynowe warto odświeżać znacznie częściej niż opisy produktów. Projektujemy obsługę konfliktów, czyli decyzję, który system wygrywa, gdy dane się rozjadą, oraz zachowanie sklepu, gdy ERP jest chwilowo niedostępny, żeby awaria po stronie systemu handlowego nie zatrzymała sprzedaży ani nie pokazała klientom fałszywych stanów. Tam, gdzie w grę wchodzi osobny system magazynowy klasy WMS, dokładamy trzeci punkt tej układanki, tak żeby rezerwacja towaru pod zamówienie i jego wydanie z magazynu opierały się na jednej, spójnej informacji o dostępności.

#Płatności po polsku i bezpieczeństwo transakcji

Polski kupujący, także ten firmowy, oczekuje polskich metod płatności, więc standardem są Przelewy24, BLIK i PayU, a przy zamówieniach B2B dokładamy do tego przelew tradycyjny i płatność odroczoną. Każdą bramkę wdrażamy z tą samą starannością: dokumentujemy obsługiwane przepływy, w tym płatności jednorazowe, zwroty i zwroty częściowe, spisujemy mapę webhooków, które bramka wysyła, i pilnujemy idempotencji, żeby powtórzone powiadomienie nie utworzyło drugiego zamówienia ani nie zaksięgowało płatności dwa razy.

Bezpieczeństwo płatności traktujemy jako część architektury, nie jako wtyczkę doklejaną na końcu. Dane karty nie przechodzą przez sklep, tylko przez środowisko bramki, komunikacja webhooków jest weryfikowana podpisem, a wrażliwe operacje na koncie klienta wymagają uwierzytelnienia. Do tego dochodzi twarda praktyka programistyczna, która chroni sklep niezależnie od bramki: parametryzowane zapytania do bazy, escapowanie danych wyjściowych, weryfikacja nonce na formularzach i ograniczanie liczby prób na endpointach logowania i składania zamówień. Sklep hurtowy jest łakomym celem, bo zna go grono kontrahentów, a nie anonimowy tłum, więc kontrola dostępu do cen i do panelu klienta bywa tu ważniejsza niż na sklepie detalicznym.

#VAT i sprzedaż transgraniczna w Unii

Warszawskie hurtownie rzadko sprzedają wyłącznie w kraju; częściej mają odbiorców w Czechach, na Słowacji, w krajach bałtyckich czy w Niemczech, a to natychmiast wciąga sklep w reguły VAT wewnątrzunijnego. Checkout musi rozpoznać, czy kupuje polska firma, unijna firma z ważnym numerem VAT UE, czy konsument, i na tej podstawie zastosować właściwą stawkę oraz właściwy sposób jej prezentacji. Weryfikacja numeru w VIES decyduje o tym, czy transakcja B2B może pójść z odwrotnym obciążeniem, więc podłączamy ją do checkoutu, a nie zostawiamy jako ręczny krok handlowca.

Do tego dochodzi kwestia sprzedaży wysyłkowej do konsumentów w innych krajach Unii i związanych z nią progów oraz procedury OSS, jeśli firma prowadzi też sprzedaż detaliczną za granicę. Nie zastępujemy tu doradcy podatkowego, ale projektujemy sklep tak, żeby generował dane spójne z przyjętym modelem rozliczeń, i uzgadniamy reguły z księgowością klienta na etapie projektu, a nie po pierwszym spornym zamówieniu. W praktyce oznacza to jasny podział: sklep liczy i pokazuje ceny według uzgodnionych reguł, a rozliczenie i deklaracje robi system finansowy na podstawie czystych danych, które sklep mu podaje.

#Wydajność dużych katalogów

Katalog hurtowy to zupełnie inne wyzwanie wydajnościowe niż sklep z kilkuset produktami. Tysiące, czasem dziesiątki tysięcy indeksów, każdy z wariantami, atrybutami i osobnymi cenami dla grup klientów, potrafią położyć sklep w miejscach, których na małym katalogu w ogóle nie widać. Doświadczenie z takich projektów mówi jasno: duże katalogi B2B najczęściej klękają nie na stronie głównej, tylko na filtrowaniu po atrybutach, na wyszukiwaniu i na masowej aktualizacji stanów z ERP.

Dlatego kolejność jest zawsze taka sama: najpierw pomiar, potem zmiana. Profilujemy zapytania do bazy, sprawdzamy, ile opcji ładuje się automatycznie przy każdym żądaniu, mierzymy czas filtrowania fasetowego i obciążenie sklepu w momencie importu cennika. Dopiero na podstawie zmierzonego wąskiego gardła dobieramy rozwiązanie: właściwe indeksy w bazie, cache obiektowy na powtarzalne zapytania, przeniesienie wyszukiwania i filtrowania poza czyste zapytania SQL tam, gdzie to się opłaca, oraz kolejkowanie ciężkich importów w tle, żeby synchronizacja z ERP nie zatrzymywała sklepu w godzinach największego ruchu. Rezultat mierzymy na tych samych metrykach co na starcie, bo optymalizacja bez pomiaru po obu stronach jest tylko przekonaniem, że coś się poprawiło.

#Trzy warszawskie wdrożenia z praktyki

Hurtownia z cennikiem w Comarchu. Dystrybutor spod Warszawy prowadził sprzedaż przez handlowców i mailowo, a cały cennik kontraktowy, z dziesiątkami grup rabatowych, żył w Comarch ERP XL. Klient chciał portal, w którym stali odbiorcy zamawiają sami, po swoich cenach, bez angażowania handlowca do każdego zamówienia. Praca zaczęła się nie od wyglądu sklepu, tylko od integracji: cennik i stany z ERP jako jedyne źródło prawdy, ceny per grupa kontrahenta, limity kupieckie odzwierciedlające ustalenia handlowe. Po uruchomieniu handlowcy przestali przepisywać zamówienia z maila do systemu, bo trafiały do ERP bezpośrednio ze sklepu, a to była realna zmiana w ich dniu pracy, nie slajd na prezentacji.

Marka D2C skalująca sprzedaż. Producent sprzedający pod własną marką bezpośrednio do klientów detalicznych i firmowych urósł do poziomu, na którym gotowy motyw zaczął mu ciążyć. Problemem nie była jedna wielka awaria, tylko suma drobnych tarć: wolny checkout, brak sensownej obsługi zamówień na firmę, płatności ograniczone do jednej bramki. Zamiast przebudowy od zera uporządkowaliśmy sklep etapami: najpierw checkout z BLIK-iem i Przelewami24 oraz obsługą NIP-u, potem wydzielenie logiki cenowej z motywu do dedykowanej wtyczki, na końcu porządek w wariantach produktów. Firma mogła sprzedawać przez cały czas trwania prac.

Sklep z tysiącami indeksów i wolnymi filtrami. Warszawski sprzedawca części zamiennych miał katalog liczony w dziesiątkach tysięcy SKU i filtry, które przy większej liczbie zaznaczonych atrybutów potrafiły ładować się kilkanaście sekund. Klienci B2B rezygnowali z szukania i wracali do dzwonienia, co przekreślało cały sens sklepu. Diagnoza pokazała, że wąskim gardłem były zapytania filtrujące uderzające wprost w bazę oraz automatycznie ładowane opcje, a dodatkowo import cennika z systemu handlowego uruchamiał się w środku dnia i dokładał obciążenia dokładnie wtedy, gdy klienci przeglądali katalog. Rozwiązanie połączyło przebudowę wyszukiwania i filtrowania z cache obiektowym, uporządkowaniem danych produktowych i przesunięciem ciężkich importów do kolejki w tle poza godziny szczytu. Filtry zaczęły odpowiadać w ułamku poprzedniego czasu, a telefon przestał być szybszy od strony produktu.

#Kiedy nie potrzebujesz dedykowanego developera WooCommerce

Ta sekcja istnieje, bo częściej odradzamy dedykowaną pracę, niż wypada przyznać stronie usługowej. Jeżeli sprzedajesz detalicznie kilkadziesiąt czy kilkaset produktów, po jednej cenie dla wszystkich, z płatnością z góry i wysyłką kurierem, to gotowy, dobrze skonfigurowany motyw plus sprawdzone wtyczki załatwiają sprawę za ułamek kosztu prac programistycznych. WooCommerce z rozsądnym zestawem rozszerzeń obsłuży taki sklep bez ani jednej linijki dedykowanego kodu, i tak jest zwyczajnie taniej.

Nie potrzebujesz dedykowanego developera również wtedy, gdy problemem jest oferta albo zdjęcia, a nie technologia; sklep ze słabym asortymentem i kiepskimi opisami nie zacznie sprzedawać po refaktoryzacji kodu. Podobnie, jeśli chcesz jednej konkretnej funkcji, którą pokrywa dojrzała, utrzymywana wtyczka, sensowniej jest jej użyć niż pisać własną. Dedykowana praca zaczyna się opłacać dopiero tam, gdzie standardowe rozwiązania trzeba obchodzić: przy cenach kontraktowych, zamówieniach na firmę, integracji z ERP i magazynem, dużym katalogu albo wymaganiach, których nie da się doklikać. Sprawdzian jest sklepowy i konkretny. Wypisz reguły, według których twój kontrahent ma widzieć swoją cenę, oraz miejsca, w których stan magazynowy i dane do faktury muszą zgadzać się z systemem handlowym. Jeżeli te reguły mieszczą się w ustawieniach dojrzałej wtyczki B2B, a synchronizacja sprowadza się do gotowego konektora, zostań przy konfiguracji i nie przepłacaj za kod. Jeżeli za każdym progiem cenowym albo za każdą integracją ciągnie się wyjątek, którego panel nie obejmuje, to jest już robota dla programisty.

#Model współpracy B2B

Pracujemy wyłącznie w modelu B2B, na umowie i fakturze VAT, ale w sklepie słowo skończone znaczy coś twardszego niż na zwykłej stronie. Etap uznajemy za zamknięty dopiero wtedy, gdy zamówienie kontrahenta przechodzi całą ścieżkę na danych produkcyjnych: od koszyka z jego ceną kontraktową, przez polską bramkę, po zaksięgowanie płatności i zejście dokumentu do ERP w formie gotowej do wydania z magazynu. Dopóki ten obieg się rwie w którymś ogniwie, prace trwają. Wycena jest indywidualna, bo koszt sklepu hurtowego zależy przede wszystkim od liczby i głębokości integracji oraz od stanu zastanego kodu, a nie od liczby podstron; zanim ją podamy, chcemy zobaczyć sklep, jego wtyczki i systemy handlowe, z którymi ma się spiąć. Kolejność etapów układamy wokół ścieżki zakupu: najpierw sam checkout z Przelewami24, BLIK-iem i obsługą NIP-u, potem warstwa cen kontraktowych per klient, na końcu dwukierunkowa synchronizacja z Comarchem albo Subiektem. Po każdym z nich sklep sprzedaje dalej na tym, co już wdrożone, i nie musi czekać na komplet, żeby przyjąć zamówienie.

Własność ustawiamy po stronie klienta od początku: kod trafia do repozytorium klienta, dostępy do hostingu, domen i bramek są na kontach klienta, a dokumentacja powstaje dla następnego zespołu, nie dla nas. Dla firm z własnym działem IT pracujemy w ich procesie, z przeglądem kodu po obu stronach i wdrożeniami w uzgodnionych oknach. Sklep budujemy tak, żeby po zakończeniu współpracy mógł go rozwijać dowolny kompetentny zespół, bo uzależnianie klienta od jednego wykonawcy uważamy za model z innej epoki.

Warto też widzieć całość oferty pod WordPressa w jednym miejscu. Jeśli obok sklepu potrzebujesz szerszej pracy programistycznej, właściwym punktem wejścia jest WordPress developer w Warszawie. Sklepy, które chcą inteligentnych opisów, wyszukiwarki rozumiejącej pytania czy rekomendacji, opisujemy przy integracji AI z WordPressem. Gdy działający już sklep potrzebuje głównie stabilnych aktualizacji i kogoś na telefon, sensowniejsza jest opieka techniczna nad WordPressem w Warszawie niż nowy projekt. A dla sklepów, które wyczerpały klasyczną optymalizację i rozważają oddzielenie frontendu od WordPressa, punktem wyjścia jest headless WordPress.

Początek jest niezobowiązujący: rozmowa o tym, co i komu sprzedajesz, oraz szybki przegląd sklepu i jego integracji. Jeżeli z przeglądu wyjdzie, że wystarczy konfiguracja albo inna, tańsza usługa, usłyszysz to wprost. Wolimy stracić jedno zlecenie niż zbudować coś, czego twój sklep nie potrzebował.

Ostatnia aktualizacja: 10 lipca 2026