Role i uprawnienia kupujących w sklepie B2B

W skrócie

• 1. Typowe role: Buyer (kupujący), Approver (zatwierdzający), Company Admin, Viewer
• 2. Granularność: limit zamówienia, kategorie, metody płatności, adresy dostawy
• 3. Implementacja: Adobe Commerce + Shopware Enterprise B2B Suite mają natywnie, Magento OS przez moduły
• 4. Praktyczne: zaczynaj prosto (2-3 role), rozszerz jeśli klienci proszą

Typowe role w sklepie B2B

1. Buyer (kupujący).

• Składa zamówienia w ramach swoich limitów
• Widzi cennik firmy
• Widzi swój koszyk i historię
• NIE zarządza innymi kontami

2. Approver (zatwierdzający).

• Wszystko co Buyer
• Plus: akceptuje zamówienia powyżej progu Buyer'ów
• Plus: widzi zamówienia pending approval

3. Company Admin.

• Wszystko co Buyer + Approver
• Plus: zarządza kontami firmy (tworzy, usuwa, edytuje role)
• Plus: zarządza adresami dostawy
• Plus: widzi pełną historię firmy

4. Viewer / Reporter / Accountant.

• Tylko czyta - historia zamówień, faktury, dokumenty
• NIE kupuje
• Często dla działu księgowości

5. Sales Representative (rzadziej).

• Handlowiec po stronie sklepu, nie klienta
• Loguje się jako klient (impersonation)
• Składa zamówienia w imieniu klienta przy telefonicznej obsłudze

6. Catalog Manager (zaawansowane).

• Definiuje katalog widoczny dla firmy
• W praktyce rzadkie (klient woli, żeby to handlowiec robił)

Granularność uprawnień

Każda rola ma zestaw uprawnień. Możesz mieć też uprawnienia per użytkownik (nadpisanie roli).

Per użytkownik:

User: Jan Nowak (rola: Buyer)
  Uprawnienia:
    - Limit zamówienia: 5 000 zł
    - Limit miesięczny: 50 000 zł
    - Restricted categories: ["Materiały biurowe", "Narzędzia"]
    - Allowed payment methods: ["Faktura z terminem"]
    - Allowed shipping addresses: ["Centrala Warszawa", "Oddział Kraków"]
    - Default shipping: "Centrala Warszawa"

Per rola (defaults):

Buyer:

• Limit: domyślnie 5 000 zł (admin może podnieść per user)
• Kategorie: wszystkie
• Metody płatności: wszystkie dozwolone firmie

Approver:

• Limit: unlimited
• Kategorie: wszystkie
• Plus: dostęp do approval workflow

Wymuszanie uprawnień

Kluczowe: uprawnienia są wymuszane na backendzie, nie tylko w UI.

Złe podejście:

• Ukryj „Narzędzia" w nawigacji dla Jana
• Ale endpoint /catalog/category/tools wciąż zwraca produkty
• Jan zmieni URL ręcznie → widzi to, czego nie powinien

Dobre podejście:

• Endpoint /catalog/category/tools sprawdza uprawnienia użytkownika
• Jeśli Jan nie ma dostępu do „Tools" → 403 Forbidden lub przekierowanie

Per warstwa:

• UI: ukrywaj to, co user nie powinien widzieć
• API: validuj uprawnienia per endpoint
• Backend: validuj uprawnienia per operation (canBuy(product, quantity))

Granica między user-level a company-level

User-level (per kupujący):

• Limit jednorazowego zamówienia
• Limit miesięczny
• Restricted categories
• Allowed addresses
• Approval threshold

Company-level (per firma):

• Cennik kontraktowy
• Limit kredytowy (całej firmy)
• Aktywny status firmy
• Kontrakt (od kiedy, do kiedy)
• Dostępne metody płatności (zależne od kontraktu)

Granica: wszystko, co dotyczy kontraktu - company-level. Wszystko, co dotyczy operacyjnej kontroli - user-level.

Workflow zarządzania rolami

Tworzenie użytkownika (przez Company Admin):

1. Admin wchodzi do panelu "Użytkownicy firmy"
2. Klika "Dodaj użytkownika"
3. Wpisuje:
   - Imię, nazwisko, email
   - Rola (Buyer / Approver / Viewer)
   - Limit jednorazowego zamówienia
   - Limit miesięczny
   - Restricted categories (jeśli)
4. System wysyła email z invite link
5. Nowy user klika link, ustala hasło, ma dostęp

Zmiana uprawnień (przez Company Admin):

1. Admin otwiera profil użytkownika
2. Edytuje limity / kategorie / role
3. Zapisuje
4. User dostaje notyfikację (opcjonalnie) "Twoje uprawnienia zostały zmienione"
5. Następny request od user'a używa nowych uprawnień

Dezaktywacja użytkownika:

1. Admin klika "Dezaktywuj" na profilu
2. User wylogowywany (sesja invalidate)
3. Historia użytkownika pozostaje w bazie
4. User przy próbie logowania widzi "Konto nieaktywne"

Implementacja w platformach

Adobe Commerce:

• Wbudowane Companies + Roles + Permissions
• Role: Default Admin, Default User (rozszerzasz)
• Permissions na poziomie resource (Magento_Sales::view_orders, Magento_Sales::place_order)
• UI: panel klienta zawiera „Manage Users"

Shopware Enterprise B2B Suite:

• Wbudowane Business Partner Management
• Roles + Granular Permissions
• Similar feature set

Magento Open Source:

• Dorabiasz przez Aheadworks B2B Suite lub Amasty Company Accounts
• Lub custom (customer attribute + ACL po stronie kontrolerów)

Custom:

• Symfony Security + Voters dla uprawnień
• Database: user, company, role, permission tables

Najczęstsze problemy

1. UI hide bez backend validation. Klasyczny błąd. Jan widzi ścieżki, zmienia URL, dostaje dostęp. Wymuszenie na backend obowiązkowe.

2. Default Admin może wszystko. Zbyt szerokie uprawnienia dla Admin. W większych firmach - separacja: Admin „techniczny" (zarządza kontami) ≠ Approver „finansowy" (akceptuje zamówienia).

3. Brak audytu. Kto zmienił komu uprawnienia? Bez logu - nie wiesz. Każda zmiana powinna być logowana z timestampem + actor.

4. Hard-coded role. Tylko Buyer i Admin, brak Approver. Klient prosi o trzecią rolę - przebudowa modelu danych.

Rozwiązanie: od początku elastyczny system ról (rola = zestaw permissions).

5. Restricted categories bez restricted search. Jan nie widzi „Narzędzia" w nawigacji, ale wyszukuje „wkrętak" - znajduje produkt. Searcz musi też respektować restrictions.

6. Brak granular permissions na metody płatności. Jan może użyć BNPL na zamówienie 5 tys. zł, ale nie powinien (firma nie chce ryzyka BNPL). UI hide nie wystarczy.

FAQ

Czy mogę mieć kilka ról per użytkownik? W większości implementacji - jedna rola. Granular permissions per użytkownik dają elastyczność. Multi-role: Adobe Commerce wspiera, Shopware częściowo.

Czy Buyer może zatwierdzać zamówienia innych Buyer'ów? Nie domyślnie. Approver/Admin dla approval. Buyer akceptuje tylko własne zamówienia (jeśli mieszczą się w jego limicie).

Czy uprawnienia można zmienić retroaktywnie? Tak, ale nie wpływają na historię. Jan miał limit 5k, zmienił się na 10k - stare zamówienia nie zmieniają się (były OK), nowe zamówienia używają nowego limitu.

Co z impersonation (Sales Rep wchodzi jako klient)? Sales Rep używa swoich uprawnień + impersonuje konkretnego użytkownika. Działania są zapisywane jako „Sales Rep X działający w imieniu Y" w audycie.

Czy uprawnienia są dziedziczone z parent-child hierarchii firm? W Adobe Commerce - częściowo. Cennik dziedziczony z parent (jeśli child nie ma własnego). Uprawnienia user-level - per user, nie dziedziczone.

Co dalej

• Pillar procesów B2B: Procesy zakupowe B2B
• Multi-account (struktura firmy): Multi-account dla organizacji
• Workflow akceptacji: Workflow akceptacji zamówień
• Cenniki (company-level): Cenniki kontraktowe