Shopware B2B: jak sprawdzić komponenty przed wyceną prac

Dealer widzi katalog w Shopware, ale nie może przekazać koszyka do zatwierdzenia. Zespół planuje już osobny moduł, choć przyczyną może być wersja, plan komercyjny albo funkcja niewłączona dla klienta. Shopware B2B należy oceniać na podstawie konkretnej instalacji, a nie listy możliwości w prezentacji. Najpierw sprawdź dostępność komponentu, potem jego konfigurację, a dopiero na końcu potrzebę prac programistycznych.

Fit-gap to porównanie wymagania biznesowego z tym, co działa, i określenie luki. Wynikiem jest mapa rozwiązań poparta dowodami: standardowy rdzeń, oficjalny komponent komercyjny, zewnętrzne rozszerzenie lub dedykowane oprogramowanie.

1. Sporządź kartę instalacji przed rozmową o funkcjach

Zapisz pełny numer zainstalowanej wersji Shopware, model wdrożenia, aktualny plan i uprawnienia umowne. Osobno odnotuj wersję i stan Shopware Commercial, aktywne komponenty B2B, zewnętrzne rozszerzenia, motyw i własne modyfikacje. Nazwa „Shopware 6” nie wystarcza: nie wyjaśnia, jakie możliwości ma właśnie Twój sklep ani co blokuje aktualizację.

Plan, rozszerzenie i aktywacja to odrębne warunki

Zgodnie z oficjalną dokumentacją, sprawdzoną 10 listopada 2026 roku, B2B Components są dostępne od planu Evolve za pośrednictwem rozszerzenia Shopware Commercial. Hasło „ma B2B” nie oznacza więc, że wszystkie funkcje są częścią każdej instalacji lub bezpłatnego rdzenia. Samo uprawnienie do korzystania nie dowodzi też, że potrzebne rozszerzenie jest zainstalowane, aktywne i skonfigurowane.

Dokumentacja wskazuje Employee Management od Shopware 6.5.6.0, a zatwierdzanie zamówień od 6.5.8.0 — w obu przypadkach z planem Evolve. To wersje wprowadzenia możliwości, a nie zalecenie pozostania przy tych starych wydaniach. Przed zmianami sprawdź aktualną zgodność platformy i Commercial; nie wybieraj wersji wyłącznie na podstawie jednego scenariusza B2B.

2. Sprawdź, komu dokładnie włączono komponenty

Dokumentacja B2B Components opisuje kilka poziomów dostępności. Funkcje dla pojedynczego klienta włącza się w jego karcie administracyjnej przez Customers → Overview. Dla grupy klientów można wstępnie określić funkcje B2B przy rejestracji; wymaga to aktywacji odpowiedniego, dostosowanego formularza rejestracji grupy.

Globalne ustawienia w Settings → Customer → B2B Components dotyczą wyłącznie nowo utworzonych klientów biznesowych. Nie stanowią zbiorczej aktualizacji istniejących firm. Jeżeli funkcja pojawiła się u nowego dealera, ale nie ma jej u dotychczasowego, najpierw porównaj ich ustawienia. Nie zlecaj skryptu migracyjnego, zanim ustalisz, czy problem rzeczywiście wymaga zmiany danych.

3. Zbuduj macierz pokrycia, a nie listę życzeń

Macierz zgodności komponentów musi zaczynać się od wyniku, który można sprawdzić. Zamiast „potrzebujemy ról firmowych” zapisz: „pracownik firmy tworzy koszyk, ale nie finalizuje zamówienia bez określonego zatwierdzenia”. Logikę biznesową ról można doprecyzować osobno, korzystając z artykułu o portalu samoobsługowym B2B; tutaj zadanie jest inne — znaleźć mechanizm w konkretnej instalacji Shopware.

Do każdego wiersza dodaj priorytet, właściciela reguły biznesowej, sposób realizacji, zależność i status. Przydatne statusy to: „potwierdzone testem”, „wymaga konfiguracji”, „wymaga aktualizacji”, „wymaga analizy”, „luka”. Nie oznaczaj nieznanej możliwości jako custom: nieznajomość dokumentacji nie dowodzi braku gotowego mechanizmu.

4. Oddziel konfigurację od rozszerzenia i prac custom

Pod określeniem „standardowe” w kosztorysach często kryją się różne rzeczy. Rozdziel rdzeń Shopware i oficjalne komponenty komercyjne: te ostatnie nie stają się bezpłatnym rdzeniem tylko dlatego, że wydaje je producent. Zewnętrzne rozszerzenie ma innego dostawcę i własny cykl wsparcia. Dedykowane oprogramowanie to kod oraz odpowiedzialność Twojego zespołu lub wykonawcy.

Kiedy wystarczy konfiguracja

Jeżeli potrzebną ścieżkę można w pełni odtworzyć po aktywacji komponentu i ustawieniu reguł, wyceniaj konfigurację, testy i szkolenie, a nie tworzenie funkcji od zera. Poproś o pokaz scenariusza w uzgodnionej konfiguracji. Wynikiem powinny być opis parametrów, dane testowe i kryterium ponownej weryfikacji po aktualizacji.

Jeżeli gotowe narzędzie pokrywa tylko część wymagania, wskaż granicę. Przykładowo samo zatwierdzenie w sklepie nie dowodzi blokowania wysyłki z powodu zadłużenia w ERP. Cena kontraktowa również wymaga osobnego sprawdzenia mechanizmu i uprawnień: z dostępności B2B Components nie wynika dostępność każdego modelu ustalania cen.

Kiedy uzasadnione są prace programistyczne

Rozważaj custom dla konkretnej niezrealizowanej reguły, a nie ogólnej „poprawy B2B”. Opisz dane wejściowe, wynik, błędy, granice odpowiedzialności i sposób aktualizacji. Przed wyborem zewnętrznego modułu sprawdź nie tylko listę możliwości, lecz także konflikty, wspierane wydania, eksport danych i to, kto usuwa awarię na styku z Commercial.

5. Przykład hipotetyczny: zatwierdzanie działa tylko dla nowych dealerów

To hipotetyczny scenariusz, nie projekt GL.ua. Hurtownik ma Shopware z planem Evolve, zainstalowany Commercial i wersję zgodną z potrzebnymi komponentami. Nowa firma ma dostęp do ścieżki zatwierdzania, dotychczasowy dealer — nie. Ponadto biznes chce blokować przekazanie zamówienia do ERP, gdy system ewidencyjny zgłasza przeterminowane zadłużenie.

Pierwszy krok nie polega na napisaniu nowego panelu klienta. Zespół porównuje aktywację komponentów dla obu firm i reguły zatwierdzania. Ponieważ ustawienia globalne dotyczą tylko nowych klientów biznesowych, osobno sprawdza kartę dotychczasowego dealera. Jeżeli po poprawnej konfiguracji scenariusz przechodzi test, ten wiersz macierzy zostaje zamknięty konfiguracją.

Reguła zadłużenia pozostaje odrębną luką do czasu sprawdzenia integracji. Przykładowe kryterium odbioru: gdy ERP potwierdzi zakaz, zamówienie nie jest przekazywane dalej, a odpowiedzialna osoba widzi przyczynę. Jeśli ERP jest niedostępny, system działa według wcześniej uzgodnionej polityki, zamiast po cichu uznawać brak zadłużenia. To wymaganie przykładu, a nie obietnica standardowego działania Shopware.

Rozwiązanie dzieli się na dwa zadania: konfigurację dostępnego komponentu i analizę sprawdzania zadłużenia. Drugie wymaga najpierw formatu odpowiedzi ERP, momentu kontroli i reguły ponawiania próby. Dopiero po teście wybiera się gotowe rozszerzenie lub kod. Dzięki temu kosztorys nie miesza naprawy konfiguracji z rzeczywiście nową logiką biznesową.

6. Przeprowadź kolejne testy przed uruchomieniem

Testy odbiorowe funkcji B2B przeprowadzaj w środowisku testowym z odpowiednią konfiguracją i zanonimizowanymi danymi. Dla każdego kroku zapisz oczekiwany wynik i faktyczny dowód.

1. Porównaj wersje Shopware, Commercial i zależnych rozszerzeń z kartą instalacji. Potwierdź uprawnienia do korzystania oraz brak nieuzgodnionych różnic między środowiskami.
2. Osobno sprawdź dotychczasowego i nowego klienta biznesowego, rejestrację przez formularz grupy oraz zwykłego kupującego. Funkcje powinny być dostępne tylko uzgodnionym kategoriom klientów.
3. Przejdź dozwoloną ścieżkę tworzenia i zatwierdzania zamówienia. Następnie spróbuj je sfinalizować jako użytkownik bez potrzebnego uprawnienia i zapisz odmowę.
4. Zmień koszyk po zatwierdzeniu, jeśli taki scenariusz jest możliwy w Twojej konfiguracji. Sprawdź, czy wynik odpowiada uzgodnionej regule ponownej kontroli.
5. Sprawdź odpowiedź ERP, jego niedostępność i ponowne wysłanie. Warunki odbioru muszą wykluczać niezauważoną utratę zamówienia i niekontrolowany duplikat.
6. Odtwórz krytyczne scenariusze po planowanej aktualizacji na kopii testowej. Sprawdź odtworzenie systemu i wycofanie zmian przed modyfikacją środowiska produkcyjnego.

7. Oceń ryzyka, składniki kosztów i zależności terminów

Główne ryzyko to uznanie nazwy komponentu za spełnione wymaganie. Inne ryzyka obejmują niezgodność zewnętrznego modułu, różne parametry środowisk, zmiany dostępności wynikające z umowy oraz własny kod bez testów regresyjnych. Dla każdego określ sposób wykrywania i osobę odpowiedzialną. Szczególnie sprawdź, czy dwa moduły nie dublują jednego procesu i nie zmieniają tych samych danych.

Koszt obejmuje inwentaryzację i fit-gap, uprawnienia do planu i rozszerzeń, aktualizację, konfigurację, integracje, programowanie, testy i szkolenie. Dodaj infrastrukturę środowiska testowego, wsparcie i ponowne kontrole po wydaniach. To odrębne pozycje kosztów: jednorazowe programowanie nie znosi regularnych opłat i utrzymania.

Terminy zależą od dostępu do instalacji i umowy, stanu aktualizacji, zgodności modułów, gotowości ERP i szybkości uzgadniania reguł. Kolejność jest następująca: karta instalacji → sprawdzenie dostępności → demonstracja ryzykownego scenariusza → ocena luk → realizacja → odbiór. Nieznanej integracji nie należy ukrywać za dokładnym terminem kalendarzowym w ogólnym kosztorysie.

Po fit-gap można przygotować porównywalne zapytanie do wykonawców: potwierdzone komponenty, niezrealizowane wymagania, dowody i wyłączenia. W wyborze formatu zakupu pomoże artykuł o RFI, RFP i RFQ dla sklepu internetowego. Przekazuj do niego sprawdzone granice, a nie założenia, że każde życzenie B2B jest częścią planu.

8. Podejmij decyzję na podstawie luk, a nie marki platformy

Dobrym wynikiem weryfikacji jest krótka lista potwierdzonych możliwości, ustawień, zależności i osobnych prac programistycznych. Jeśli obecny Shopware obsługuje krytyczne scenariusze, sama złożoność początkowej konfiguracji nie uzasadnia zmiany platformy. Jeśli luki są istotne, porównuj warianty według jednakowych reguł odbioru i pełnego kosztu wsparcia.

Aby omówić architekturę biznesową systemu internetowego na Drupal, skontaktuj się z GL.ua (Glyanec) przez stronę tworzenia stron dla biznesu. Przygotuj mapę wymagań, właścicieli danych i zweryfikowane luki. To podstawa rzeczowej konsultacji, a nie obietnica wdrożenia Shopware ani zalecenie obowiązkowej wymiany platformy.