Shopware B2B: як перевірити компоненти до оцінки доопрацювань

Дилер бачить каталог у Shopware, але не може передати кошик на погодження. Команда вже планує окремий модуль, хоча причина може бути у версії, комерційному плані або неввімкненій функції для клієнта. Shopware B2B варто оцінювати не за переліком можливостей у презентації, а за конкретною інсталяцією. Спочатку перевірте доступність компонента, потім його налаштування й лише після цього — потребу в доопрацюванні.

Fit-gap — це зіставлення бізнес-вимоги з тим, що працює, і визначення розриву. Результат — карта рішень із доказами: штатне ядро, офіційний комерційний компонент, стороннє розширення або власна розробка.

1. Зафіксуйте паспорт інсталяції до обговорення функцій

Запишіть повний номер встановленої версії Shopware, спосіб розгортання, чинний план і договірні права. Окремо зафіксуйте версію та стан Shopware Commercial, активні B2B-компоненти, сторонні розширення, тему й власні зміни. Назва «Shopware 6» недостатня: вона не пояснює, які можливості доступні саме вашому магазину та що заважає оновленню.

План, розширення й активація — різні умови

За офіційною документацією, перевіреною 10 листопада 2026 року, B2B Components доступні починаючи з плану Evolve через розширення Shopware Commercial. Отже, напис «є B2B» не означає, що всі функції входять у будь-яку інсталяцію чи безплатне ядро. Наявність права користування також не доводить, що потрібне розширення встановлене, активне й налаштоване.

Документація вказує Employee Management від Shopware 6.5.6.0, а погодження замовлень — від 6.5.8.0, в обох випадках із планом Evolve. Це пороги появи можливостей, а не рекомендація залишатися на цих старих версіях. Перед змінами звірте актуальну сумісність платформи та Commercial; не підбирайте версію лише за одним B2B-сценарієм.

2. Перевірте, кому саме ввімкнено компоненти

У документації B2B Components описано кілька рівнів доступності. Для окремого клієнта функції вмикаються в адміністративній картці через Customers → Overview. Для групи клієнтів можна попередньо визначити B2B-функції під час реєстрації; для цього потрібно активувати відповідну індивідуалізовану форму реєстрації групи.

Глобальні значення в Settings → Customer → B2B Components застосовуються лише до новостворених бізнес-клієнтів. Вони не є масовим оновленням чинних компаній. Якщо функція з’явилася у нового дилера, але відсутня у давнього, спочатку порівняйте їхні налаштування. Не замовляйте міграційний скрипт, поки не з’ясували, чи проблема справді потребує зміни даних.

3. Складіть матрицю покриття, а не список побажань

Матриця сумісності компонентів має починатися з перевірюваного результату. Замість «потрібні корпоративні ролі» запишіть: «співробітник компанії створює кошик, але не завершує замовлення без визначеного погодження». Бізнес-логіку ролей можна окремо уточнити за матеріалом про B2B-портал самообслуговування; тут завдання інше — знайти механізм у конкретній Shopware-інсталяції.

Для кожного рядка додайте пріоритет, власника бізнес-правила, спосіб реалізації, залежність і статус. Корисні статуси: «підтверджено тестом», «потрібне налаштування», «потрібне оновлення», «потрібне дослідження», «розрив». Не позначайте невідому можливість як custom: незнання документації не є доказом відсутності готового механізму.

4. Відокремте налаштування від розширення та custom

Під «штатним» у кошторисах нерідко ховають різні речі. Розділіть ядро Shopware та офіційні комерційні компоненти: останні не стають безплатним ядром лише тому, що їх випускає виробник. Стороннє розширення має іншого постачальника й власний цикл підтримки. Власна розробка — це код і відповідальність вашої команди або підрядника.

Коли достатньо конфігурації

Якщо потрібний маршрут повністю відтворюється після активації компонента та налаштування правил, оцінюйте конфігурацію, тестування і навчання, а не створення функції з нуля. Попросіть показати сценарій на погодженій конфігурації. У результаті мають залишитися опис параметрів, тестові дані та критерій повторної перевірки після оновлення.

Якщо готовий засіб покриває лише частину вимоги, вкажіть межу. Наприклад, наявне погодження в магазині саме по собі не доводить блокування відвантаження за боргом в ERP. Договірна ціна також потребує окремої перевірки механізму та прав користування: із доступності B2B Components не можна виводити доступність будь-якого ціноутворення.

Коли виправдане доопрацювання

Custom розглядайте для конкретного незакритого правила, а не для «покращення B2B» загалом. Опишіть вхідні дані, результат, помилки, межі відповідальності та спосіб оновлення. Перед вибором стороннього модуля перевірте не лише картку можливостей, а й конфлікти, підтримувані релізи, експорт даних і те, хто усуває збій на стику з Commercial.

5. Умовний приклад: погодження працює лише для нових дилерів

Це гіпотетичний сценарій, не кейс GL.ua. Оптовик має Shopware із планом Evolve, встановлений Commercial і версію, що відповідає потрібним компонентам. Новій компанії доступний маршрут погодження, давньому дилеру — ні. Крім того, бізнес хоче забороняти передавання замовлення в ERP, якщо облікова система повідомляє про прострочений борг.

Перша перевірка — не написання нового кабінету. Команда порівнює активацію компонентів для двох компаній і правила погодження. Оскільки глобальні налаштування стосуються лише нових бізнес-клієнтів, для чинного дилера окремо перевіряють його картку. Якщо після коректного налаштування сценарій проходить, цей рядок матриці закривається конфігурацією.

Правило боргу залишається окремим розривом до перевірки інтеграції. Умовний критерій приймання: за підтвердженої заборони від ERP замовлення не передається далі, а відповідальний бачить причину. Якщо ERP недоступна, система діє за наперед погодженою політикою, а не мовчки вважає борг відсутнім. Це вимога прикладу, не обіцянка штатної поведінки Shopware.

Рішення розбивають на дві роботи: налаштування доступного компонента та дослідження перевірки боргу. Для другої спочатку потрібні формат відповіді ERP, момент перевірки й правило повторної спроби. Тільки після тесту обирають готове розширення або код. Так кошторис не змішує усунення помилки конфігурації зі справді новою бізнес-логікою.

6. Проведіть послідовні тести до запуску

Приймання B2B-функцій проводьте на тестовому середовищі з відповідною конфігурацією та знеособленими даними. Для кожного кроку запишіть очікуваний результат і фактичний доказ.

1. Звірте версії Shopware, Commercial і залежних розширень із паспортом. Підтвердьте права користування та відсутність непогоджених змін між середовищами.
2. Перевірте окремо чинного й нового бізнес-клієнта, реєстрацію через форму групи та звичайного покупця. Функції мають відкриватися лише погодженим категоріям клієнтів.
3. Пройдіть дозволений маршрут створення й погодження замовлення. Потім спробуйте завершити його користувачем без потрібного права та зафіксуйте відмову.
4. Змініть кошик після погодження, якщо такий сценарій можливий у вашій конфігурації. Перевірте, що результат відповідає погодженому правилу повторного контролю.
5. Перевірте відповідь ERP, її недоступність і повторне надсилання. Умови приймання мають виключати непомітну втрату замовлення та неконтрольований дубль.
6. Відтворіть критичні сценарії після запланованого оновлення на тестовій копії. Перевірте відновлення та відкат до зміни робочого середовища.

7. Оцініть ризики, складові вартості та залежності строків

Головний ризик — прийняти назву компонента за виконану вимогу. Інші ризики: несумісність стороннього модуля, різні параметри середовищ, зміни доступності за договором і власний код без регресійних тестів. Для кожного визначте спосіб виявлення та відповідального. Особливо перевірте, чи не дублюють два модулі один процес і чи не змінюють вони одні й ті самі дані.

Вартість складається з інвентаризації та fit-gap, прав користування планом і розширеннями, оновлення, конфігурації, інтеграцій, доопрацювань, тестування й навчання. Додайте інфраструктуру тестового середовища, підтримку та повторні перевірки після релізів. Це різні статті витрат: разова розробка не скасовує регулярних платежів і супроводу.

Строки залежать від доступу до інсталяції та договору, стану оновлень, сумісності модулів, готовності ERP і швидкості погодження правил. Послідовність така: паспорт → перевірка доступності → демонстрація ризикового сценарію → оцінка розривів → реалізація → приймання. Невідому інтеграцію не варто маскувати точним календарним строком у загальному кошторисі.

Після fit-gap можна підготувати зіставний запит виконавцям: підтверджені компоненти, незакриті вимоги, докази та винятки. Формат закупівлі допоможе обрати матеріал про RFI, RFP та RFQ для інтернет-магазину. До нього передавайте вже перевірені межі, а не припущення, що будь-яке B2B-побажання входить у план.

8. Прийміть рішення за розривами, а не за брендом платформи

Хороший результат перевірки — короткий перелік підтверджених можливостей, налаштувань, залежностей і окремих доопрацювань. Якщо чинний Shopware закриває критичні сценарії, немає підстав змінювати платформу лише через складність первинної конфігурації. Якщо розриви суттєві, порівнюйте варіанти за однаковими правилами приймання та повною вартістю підтримки.

Для обговорення бізнес-архітектури вебсистеми на Drupal зверніться до GL.ua (Глянець) через сторінку розробки сайтів для бізнесу. Підготуйте карту вимог, власників даних і перевірені розриви. Це основа предметної консультації, а не обіцянка впровадження Shopware чи рекомендація обов’язково замінити вашу платформу.