Ceny per kontrahent na Magento 2.4.7: jak to spiąć bez zarżnięcia bazy danych?
Czyste Magento 2 Open Source po wyjęciu z pudełka oferuje grupy klientów (Customer Groups) i ceny schodkowe (Tier Prices), co wystarcza przy prostej sprzedaży hurtowej z rabatem 5%, 10% czy 15%. Schody zaczynają się w momencie, gdy obsługujesz 1200 kontrahentów B2B, a każdy z nich ma wynegocjowaną osobną stawkę na wybrane 400 z 30 000 produktów w katalogu. Jeśli planujesz wdrozenia Magento 2 i Adobe Commerce pod taki model, musisz od razu podjąć decyzję architektoniczną: czy bazujesz na natywnym indeksowaniu cen, czy na dedykowanej tabeli narzutów synchronizowanej w czasie rzeczywistym z Comarch ERP Optima lub Subiektem nexo/GT.
Próba wciśnięcia 500 000 unikalnych wierszy cenowych w natywny mechanizm catalog_product_index_price na Magento 2.4.7 z PHP 8.3 i OpenSearch 2.12 skończy się paraliżem bazy MySQL podczas każdego zapisu produktu. Standardowy reindeks cen zacznie trwać 40 minut zamiast 15 sekund, a serwer zacznie rzucać SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded. U nas w projektach SISL rozwiązujemy ten problem dwutorowo, zależnie od skali:
- Dla katalogów do 20 000 SKU i do 100 grup rabatowych: Stosujemy rozszerzenia pokroju Amasty Customer Specific Pricing lub Mageworx Prices per Customer, które mapują reguły cenowe bezpośrednio na ID klienta lub strukturę cenników z ERP, utrzymując buforowanie cen w Redis.
- Dla hurtowni enterprise (50 000+ SKU, cennik per NIP): Omijamy natywny indeks cenowy Magento dla widoku B2B. Katalog wyświetla ceny bazowe lub ostatnio pobrane ceny zbuforowane, natomiast rzeczywista cena per klient jest pobierana asynchronicznie przez lekki endpoint GraphQL/REST wprost z pamięci podręcznej Redis zasilanej webhookami z ERP.
Jak zintegrować limity kupieckie i odroczoną płatność z Subiektem lub Optimą?
Odroczony termin płatności (np. przelew 14, 30 lub 60 dni) to standard w polskim handlu B2B, ale udostępnienie go klientowi w koszyku bez twardej weryfikacji salda to proszenie się o zatory płatnicze. Magento 2 nie powinno być źródłem prawdy o finansach kontrahenta — tę rolę zawsze pełni system ERP (Subiekt GT, Subiekt nexo PRO, Comarch ERP Optima czy Enova365).
Prawidłowo wdrożony moduł kredytu kupieckiego (Company Credit) działa w oparciu o cztery parametry przesyłane z ERP do profilu klienta w Magento:
- Przyznany limit kupiecki (np. 50 000 PLN brutto): Maksymalna kwota zadłużenia.
- Bieżące saldo zadłużenia: Suma niezapłaconych faktur (w tym zaciągniętych poza sklepem internetowym, np. przez przedstawiciela handlowego).
- Kwota zamówień w realizacji: Wartość koszyków złożonych, ale jeszcze niezrealizowanych i niezaksiegowanych w ERP.
- Blokada przeterminowanych płatności: Flaga logiczna (0/1), która automatycznie blokuje metodę płatności „Przelew odroczony”, jeśli kontrahent zalega z jakąkolwiek fakturą powyżej ustalonej liczby dni (np. 7 dni po terminie).
Weryfikacja limitu musi odbywać się dwukrotnie: na etapie renderowania metod płatności w checkout oraz bezpośrednio przed wywołaniem metody sales_order_place_after. Jeśli zamówienie przekracza dostępny limit o choćby 1 PLN, bramka odroczona jest ukrywana, a klient ma do dyspozycji wyłącznie przedpłatę przez Przelewy24 (BLIK, szybki przelew) lub kartę płatniczą.Dodatkowo przy rejestracji firmy i wpisaniu numeru NIP wdrożenie musi automatycznie weryfikować kontrahenta w bazie GUS (pobranie nazwy i adresu) oraz sprawdzać status na Białej Liście Podatników VAT (API Ministerstwa Finansów). Pozwala to wyeliminować błędy w danych fakturowych, zanim trafią one do JPK_V7 i Krajowego Systemu e-Faktur (KSeF).
Quick Order i zamówienia zbiorcze z CSV: jak nie zabić koszyka przy 400 pozycjach?
Klienci hurtowi nie przeklikują się przez drzewo kategorii ani nie oglądają zdjęć w galerii. Ich proces zakupowy to albo wklejenie listy SKU z arkusza Excel, albo wgranie pliku .csv z kodami kreskowymi EAN i liczbą sztuk. Moduł szybkiego zamawiania (Quick Order / Matrix Order) to fundament wdrożenia B2B.
Natywne dodanie 300 produktów do standardowego koszyka Magento w jednym żądaniu HTTP potrafi zająć ponad 12 sekund, ponieważ silnik domyślnie przelicza reguły koszykowe, podatki, dostępność magazynową i koszty wysyłki osobno dla każdej dodawanej linii zamówienia. Aby Quick Order działał płynnie (czas reakcji poniżej 1.5 sekundy), optymalizujemy ten proces na poziomie kodu:
- Masowa walidacja SKU: Jedno zapytanie do OpenSearch 2.x weryfikujące istnienie kodów i stany magazynowe (MSI — Multi-Source Inventory), zamiast odpytywania bazy w pętli
foreach. - Zbiorcze dodawanie do obiektu Quote: Zastąpienie standardowego
addProduct()dedykowaną operacją masowego wstrzykiwania pozycji z jednorazowym wywołaniemcollectTotals()na samym końcu transakcji. - Frontend oparty o Hyvä Themes lub Alpine.js: Interfejs wklejania kodów pozwala na edycję ilości w czasie rzeczywistym bez przeładowywania drzewa DOM, co eliminuje narzut ciężkich komponentów Knockout.js z domyślnego motywu Luma.
Efekt? Hurtownik wgrywa plik CSV z 250 pozycjami, system w ułamku sekundy oznacza kolorem czerwonym dwa niedostępne produkty z propozycją zamienników, a pozostałe 248 pozycji trafia natychmiast do koszyka z poprawnie naliczonymi rabatami indywidualnymi.
Adobe Commerce B2B czy Magento Open Source z modułami? Zestawienie kosztów i TCO
Jedno z pierwszych pytań inwestorów brzmi: czy musimy kupować licencję Adobe Commerce (dawniej Magento Enterprise), czy wystarczy darmowe Magento Open Source rozbudowane o moduły komercyjne? Odpowiedź zależy od obrotu firmy i złożoności struktury zakupowej.
W SISL nie naciągamy klientów na licencję Adobe Commerce, jeśli ich model biznesowy tego nie uzasadnia. Poniżej twarde zestawienie kosztów i możliwości obu ścieżek:
- Wariant 1: Magento Open Source + stack modułów B2B (np. Amasty B2B Suite / Mirasvit / Hyvä)
Koszt licencji oprogramowania: 0 PLN za Magento + ok. 1 500 – 3 000 EUR jednorazowo za pakiety modułów (Company Accounts, Quick Order, Custom Pricing, Credit Limit).
Dla kogo: Firmy z obrotem B2B do 50-100 mln PLN rocznie, standardową strukturą rabatowania i prostym podziałem ról w firmie klienta (właściciel + pracownicy składający zamówienia). Całkowity koszt wdrożenia takiego systemu zamyka się zazwyczaj w granicach 60 000 – 140 000 PLN netto. - Wariant 2: Oficjalny Adobe Commerce B2B
Koszt licencji: od ok. 25 000 USD do nawet 60 000+ USD rocznie (uzależniony od Gross Merchandise Value — GMV).
Dla kogo: Korporacje i międzynarodowi dystrybutorzy potrzebujący zaawansowanych matryc akceptacji zamówień (np. dyrektor zatwierdza koszyki powyżej 20 000 PLN, kierownik do 5 000 PLN), negocjacji ofert handlowych wewnątrz platformy (Request for Quote) oraz natywnego wsparcia dla setek stron i walut z centralnym zarządzaniem prawami dostępu. Koszt wdrożenia enterprise startuje zwykle od 180 000 PLN w górę.
Polska specyfika B2B: KSeF, kurierzy paletowi i faktury z odroczonym terminem
Wdrażając platformę B2B na polskim rynku, nie można pominąć integracji z otoczeniem prawno-logistycznym. Standardowy moduł wysyłkowy z wtyczką Paczkomatów InPost nie wystarczy, gdy zamówienia hurtowe ważą po 400 kg i wymagają wysyłki na paletach przemysłowych (np. przez Raben, Schenker czy Rohlig Suus z automatycznym generowaniem listów przewozowych i kalkulacją wagi gabarytowej w koszyku).
Kolejny aspekt to Krajowy System e-Faktur (KSeF). Sklep B2B na Magento nie generuje faktury ostatecznej — wysyła zamówienie (Order) do systemu ERP, skąd dokument sprzedażowy po przetworzeniu i nadaniu numeru KSeF wraca do panelu klienta w Magento jako plik PDF oraz ustrukturyzowany XML. Dzięki temu hurtownik pobiera faktury spełniające wszystkie wymogi fiskalne bezpośrednio ze swojego panelu B2B, bez konieczności angażowania działu księgowości dystrybutora.
Jeśli szukasz zespołu, który nie uczy się B2B na Twoim budżecie i potrafi spiąć cenniki per NIP z wydajnością rzędu setek zapytań na sekundę, napisz do nas — przeanalizujemy strukturę Twojej bazy danych i dobierzemy architekturę, która udźwignie skalę Twojego hurtu bez niespodzianek przy wdrożeniu produkcyjnym.