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 или рекомендация обязательно заменить вашу платформу.