Przejdź do treści
Procesy B2B 5 min czytania

Multi-account dla organizacji - company structure w sklepie B2B

Klient w sklepie B2C = jedna osoba z jednym mailem i hasłem. Klient w sklepie B2B = firma z kilkoma kupującymi, jednym dyrektorem zakupów, czasem księgową z dostępem do historii zamówień. Model „jeden user = jeden klient" rozsypuje się natychmiast. Multi-account to mechanizm, który pozwala wielu osobom kupować w imieniu jednej firmy z zachowaniem uprawnień i kontroli.

Jakub Owsianka Autor
Zaktualizowano:
Okladka artykulu: Multi-account dla organizacji - company structure w sklepie B2B (kategoria: Procesy B2B)
Okladka artykulu: Multi-account dla organizacji - company structure w sklepie B2B (kategoria: Procesy B2B)
Spis treści (10)

W skrócie

  • 1. Struktura: Firma → Użytkownicy z rolami
  • 2. Cenniki: per firma (wszyscy użytkownicy widzą to samo)
  • 3. Koszyki i historia: per użytkownik, z dostępem dla admina firmy
  • 4. Uprawnienia: szczegółowe (kategorie, limity, metody płatności)
  • 5. Implementacja: Adobe Commerce / Shopware Enterprise B2B Suite mają natywnie, Magento OS przez moduły

Model danych

Firma (Company)
  ├── ID, nazwa, NIP, REGON, adresy
  ├── Cennik kontraktowy (ID w ERP)
  ├── Limit kredytowy
  └── Użytkownicy:
       ├── User 1 (admin) - rola Company Admin
       ├── User 2 (kupujący) - rola Buyer, limit 5k zł
       ├── User 3 (zatwierdzający) - rola Approver
       └── User 4 (księgowa) - rola Viewer (tylko czyta historię)

Cena kontraktowa, limit, kontrakt - atrybuty firmy. Użytkownicy ich dziedziczą.

Koszyki, historia własna, role - atrybuty użytkownika.

Onboarding firmy

Najczęściej:

1. Klient rejestruje się jako Company Admin. Wpisuje NIP firmy. Sklep waliduje (GUS, NIP-7), tworzy konto firmy i konto admina.

2. Sklep czeka na aktywację handlową. Handlowiec sprawdza klienta (czy faktycznie firma, czy chcemy z nią pracować), ustawia limit kredytowy i cennik w ERP.

3. Aktywacja. Klient (Admin) dostaje email „konto aktywne, możesz kupować".

4. Admin tworzy konta dla swoich kupujących. W panelu „Zarządzaj kontami firmy" admin dodaje pracowników z rolami.

5. Każdy pracownik dostaje invite (link aktywacyjny).

Cenniki na poziomie firmy

Cennik kontraktowy jest atrybutem firmy, nie użytkownika. Wszystkie osoby w firmie ACME widzą te same ceny.

W Magento Adobe Commerce: Companies → Shared Catalog. Cały katalog widzialny dla firmy.

W Shopware: Business Partner Management → Customer Specific Prices przypisane do firmy.

W Magento OS z modułami: customer_group dla firmy, użytkownicy w grupie firmy.

Koszyki i historia

Koszyk per użytkownik. Anna pakuje swój koszyk, Janek swój. Niezależnie.

Historia per użytkownik. Anna widzi swoje zamówienia. Janek swoje.

Widok firmy (dla admina). Company Admin widzi historię wszystkich użytkowników firmy. Może filtrować per user.

Wspólny koszyk (opcja). Niektóre platformy pozwalają na „shared cart" - wszyscy w firmie mogą dodawać do jednego koszyka, jedna osoba kupuje. Use-case: dział produkcji robi listę, dyrektor zatwierdza w jednym koszyku.

Onboarding nowych użytkowników

Admin firmy dodaje konto:

Imię: Anna Kowalska
Email: a.kowalska@acme.pl
Rola: Buyer
Limit jednorazowego zamówienia: 5000 zł
Limit miesięczny: 50000 zł
Restricted categories: [Materiały biurowe, Narzędzia]

System wysyła email do Anny z invite link. Anna klika, ustala hasło, ma dostęp.

Anna nie musi wpisywać NIP-u, kontraktu itp. - wszystko dziedziczone z firmy.

Self-service vs. manual admin

Self-service (przez Company Admin):

  • Dodawanie / usuwanie kont
  • Zmiana ról i limitów
  • Adresy dostawy firmy (predefiniowane)
  • Resetowanie haseł

Manual (przez sklep / handlowca):

  • Zmiana limitu kredytowego (kontrakt!)
  • Zmiana cennika
  • Blokowanie / odblokowanie firmy
  • Zmiana NIP / podstawowych danych

Granica: wszystko, co dotyczy kontraktu i finansów - manual. Wszystko, co dotyczy struktury firmy w sklepie - self-service.

Wiele oddziałów / branch'y

Większe firmy mają oddziały. Czasem ACME Sp. z o.o. = centrala + 5 oddziałów (Warszawa, Kraków, Wrocław, Gdańsk, Poznań).

Model 1: Płaski. Wszystkie oddziały to ta sama firma w sklepie. Użytkownicy tagowani „oddział X".

Model 2: Parent-child. Centrala (parent) + sub-companies (children oddziały). Każdy oddział może mieć własny limit (sub-limit z głównego), własny adres, własne raporty.

Model 3: Osobne firmy. Każdy oddział to osobne konto firmy w sklepie. Brak relacji parent-child.

Model 1 dla mniejszych. Model 2 dla większych korporacji. Model 3 rzadko, gdy oddziały są autonomiczne finansowo.

Implementacja:

  • Adobe Commerce: Companies wspierają hierarchię (parent-child) od 2.4+
  • Shopware EE B2B Suite: hierarchia firm
  • Custom: zazwyczaj parent-child relacja w bazie

Wspólne adresy dostawy

Klient B2B często dostarcza do wielu lokalizacji. Magazyn główny + 4 oddziały + biuro głównej księgowej. Klient nie chce wpisywać adresu za każdym razem.

Predefined addresses (per firma):

  • Admin firmy zarządza listą adresów dostawy
  • Każdy kupujący wybiera z listy
  • Każdy adres ma opcjonalnie:
    • Domyślny dla użytkownika
    • Restricted (tylko niektórzy mogą wysyłać tam)
    • Z notatką („cargo entrance from back")

Sales Representative - handlowiec w panelu

Klient B2B czasem dzwoni do handlowca: „złóż za mnie zamówienie X". Sales Representative w sklepie:

  • Loguje się jako handlowiec
  • Wybiera klienta (firmę) z listy
  • „Wchodzi" jako ten klient (impersonation)
  • Składa zamówienie w jego imieniu (z jego cennikiem, limitami)
  • Wyloguje się, klient nie wie że ktoś działał

Wartość: szybka obsługa B2B przez telefon. Klient nie musi się logować, handlowiec robi to za niego.

Najczęstsze problemy

1. Brak walidacji NIP przy rejestracji. Klient rejestruje się z fake NIP. Po tygodniu odkrywasz fraud.

Rozwiązanie: walidacja przez GUS (white list firm) + manualny review pierwszego zamówienia.

2. Admin firmy traci dostęp (odchodzi z pracy). Konto Company Admin pozostaje, ale nikt nie zna hasła.

Rozwiązanie: zawsze 2+ adminów per firmy. Recovery procedure dla utraty dostępu (kontakt z handlowcem).

3. Cennik per użytkownik zamiast firmy. Klasyczny błąd. Cennik nie powinien być per user (anomalia danych).

4. Brak separacji koszyków. Anna pakuje koszyk, Janek wchodzi, widzi koszyk Anny. Chaos.

5. Restricted categories nie egzekwowane. Konfiguracja w panelu „Anna nie widzi narzędzi", ale w API endpoint zwraca pełen katalog.

6. Aktywacja konta bez walidacji. Anna otrzymała invite, kliknęła, jest zalogowana - ale nie sprawdziliśmy, czy faktycznie istnieje w firmie.

Rozwiązanie: Email validation + opcjonalnie 2FA przy pierwszym logowaniu.

FAQ

Czy każda firma musi mieć Company Admin? Tak, przynajmniej jednego. Bez admin'a nie ma kto zarządzać kontami. W praktyce - 2 adminów (recovery).

Czy mogę mieć kupującego bez firmy? W Magento Adobe Commerce - tak, B2B i B2C współistnieją. „Guest" i „individual" kupują standardowo, „company" - przez Company structure.

Czy klient B2B widzi gdy admin go usunie? Tak - przy próbie zalogowania widzi „konto nieaktywne, skontaktuj się z administratorem firmy".

Co z historią zamówień użytkownika, który odszedł z firmy? Pozostaje w bazie (audyt, statystyki). Admin firmy ma do niej dostęp. Sam user nie loguje się więcej.

Czy mogę mieć 1000 użytkowników w firmie? Adobe Commerce / Shopware EE - tak (nie ma limitu w produkcie). W praktyce ponad 50 użytkowników w jednej firmie to rzadkie, ale możliwe.

Co dalej

O autorze

Jakub Owsianka

Architekt rozwiązania w WiseB2B - silniku platform B2B. Zaczynał po stronie biznesu (własne sklepy), potem deweloper, dziś projektuje wdrożenia dla sklepów z katalogami w dziesiątkach tysięcy SKU. W ostatnich latach wdrożył AI-development w zespole i funkcjonalności oparte o AI bezpośrednio w silniku sklepu.

Masz pytanie do tego artykułu?

Dodatkowy kontekst, problem z własnym wdrożeniem, druga opinia - napisz wprost. Odpowiadam osobiście w 1-2 dni robocze.