[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f22nwnkvuuhc5e":3},{"slug":4,"title":5,"published":6,"publishedAt":7,"createdAt":8,"section":9,"preview":10,"heroImage":11,"previewImage":11,"headMarkup":12,"lifecycleId":13,"bodyMd":14,"bodyHtml":15},"razrabotka-b2b-portala-s-katalogom-chem-on-otlichaetsya-ot-obychnogo-magazina","Разработка B2B-портала с каталогом: сценарии и доступы",true,"2024-07-20T10:00:00+03:00","2026-09-06T16:09:28.288Z","Статьи","B2B-портал с каталогом строится вокруг правил доступа и маршрутов заявок. Для проекта заранее определяют структуру данных, роли пользователей и обмен с учётн...","\u002Fcontent-media\u002Farticles\u002Frazrabotka-b2b-portala-s-katalogom-chem-on-otlichaetsya-ot-obychnogo-magazina\u002Fassets\u002F6af6ba218967.webp",[],"lc_14a98ace40fc9ccb94e216601a57353e","Закупщик находит нужную позицию в каталоге, но не понимает, доступна ли она его организации, можно ли включить её в заявку и требуется ли внутреннее согласование. Менеджер получает обращение без реквизитов, спецификации или состава заказа. Каталог при этом существует, однако условия приходится уточнять в переписке и таблицах.\n\nРазработка B2B-портала с каталогом начинается с описания закупочного процесса. На одной площадке могут работать сотрудники разных компаний, подразделения одного клиента, дилеры, сервисные партнёры и сотрудники поставщика. Для каждой группы определяют доступ к товарам, данным и действиям.\n\n## B2B-портал и интернет-магазин: различия в оформлении заказа\n\nОбычный интернет-магазин рассчитан на самостоятельное оформление: посетитель выбирает товар, добавляет его в корзину, оставляет контактные данные и передаёт заказ в обработку. Для большинства посетителей сценарий одинаков.\n\nВ B2B-портале товар может быть частью заявки. Пользователь собирает позиции для расчёта, прикладывает техническое задание, указывает объект поставки или выбирает организацию. Заявка может проходить внутреннее согласование и проверку со стороны поставщика.\n\nДо проектирования полезно зафиксировать маршрут заявки: кто ищет товар, кто формирует состав, кто согласует его у клиента, какие сведения получает поставщик и что происходит после отправки. Иначе корзина и форма заказа останутся интерфейсом для ручной обработки.\n\n## Структура каталога и состав товарных данных\n\nКаталог должен помогать закупщику и техническому специалисту сопоставить позицию со своей задачей: сравнить варианты, открыть документы, добавить товар в заявку. Для сложного ассортимента недостаточно названия, изображения и краткого описания.\n\nКатегории строят с учётом реального поиска. Навигация может опираться на тип оборудования, область применения, совместимость или производителя. Одна позиция иногда относится к нескольким разделам, поэтому правила размещения нужно определить заранее.\n\nДля каждого типа товара задают набор полей: параметры, варианты исполнения, единицы измерения, файлы, связанные позиции и признаки доступности. Фильтры дают предсказуемый результат, когда значения заполняются по единым правилам. Если одно и то же свойство вносится в свободной форме или отсутствует в части карточек, выдача становится неполной.\n\n## Личный кабинет и роли пользователей\n\nОдин контрагент нередко представлен несколькими сотрудниками. Закупщик готовит заявку, руководитель согласует её, бухгалтер работает с документами, а технический специалист проверяет параметры. Этим пользователям не требуется одинаковый набор прав.\n\nВ требованиях отдельно описывают роли и границы видимости. Важно определить, видит ли сотрудник заявки коллег, имеет ли доступ к истории обращений организации, может ли менять реквизиты и адреса или только создавать черновик.\n\nОтдельно предусматривают изменение состава пользователей: увольнение, перевод в другое подразделение, ошибочное назначение роли. Данные сотрудника и данные организации не стоит объединять в одной модели без правил доступа. Контактное лицо, договор, адрес поставки и условия оформления относятся к разным сущностям и могут иметь разные ограничения видимости.\n\n## Доступ к ассортименту и правила оформления заявок\n\nРазным группам пользователей может быть доступен разный ассортимент и разные способы оформления. Такие правила не стоит оставлять только в программной логике. До разработки определяют, от каких признаков зависит отображение товара, где хранится источник данных и кто поддерживает сведения в актуальном состоянии.\n\nДля товаров, которые нельзя оформить по стандартному сценарию, предусматривают отдельный маршрут: запрос на расчёт, сбор спецификации или передача заявки менеджеру. Пользователь должен понимать, что именно передаётся: отдельная позиция, набор товаров, проектная потребность или повторный заказ по ранее согласованному составу.\n\nПри тестировании проверяют исключения: организацию без назначенных условий, товар с неполными данными, изменившийся статус позиции, несколько условий для одной компании. Такие ситуации стоит предусмотреть ещё на этапе проектирования и тестирования.\n\n## Интеграции B2B-портала и обмен данными\n\nФормулировка «нужна интеграция с учётной системой» не определяет состав работ. Для портала перечисляют объекты обмена и действия, в которых они участвуют: товары, параметры, статусы заявок, реквизиты организаций, документы, история заказов.\n\nДля каждого объекта определяют источник данных, направление передачи и правило сопоставления идентификаторов. Также заранее решают, что происходит при ошибке: где она фиксируется, кто разбирает проблему, можно ли повторить передачу и как обрабатываются неполные сведения. Иначе товар может появиться без обязательных полей, а заявка — без связи с нужной организацией.\n\n«1С-Битрикс: Управление сайтом» может использоваться для публичной части портала и личного кабинета в рамках настроенного проекта. CMS не заменяет процессы обработки заявок и не определяет, кто принимает решение по ним.\n\n## Как определить границы разработки\n\nПри выборе подхода оценивают не только перечень экранов, но и рабочие сценарии. Каталог, карточка товара и личный кабинет могут выглядеть похоже, но отличаться правилами доступа к ассортименту, составом заявки, согласованием, документами и обменом данными.\n\nДо начала работ нужны реальные примеры: обычные товары, позиции с вариантами, карточки с неполными данными, товары под запрос и повторные заказы. На таких примерах проще проверить структуру каталога, фильтры, права пользователей и логику оформления.\n\nС подрядчиком важно согласовать границы решения: какие сценарии входят в проект, какие данные предоставляет заказчик, кто поддерживает каталог и какие условия требуют отдельного описания. Это помогает избежать ситуации, когда слово «портал» по-разному понимают участники проекта.\n\n## Проверка B2B-каталога перед запуском\n\nТестирование не сводится к просмотру карточек на тестовых данных. Проверяют путь каждого типа пользователя: поиск, фильтрацию, выбор варианта, формирование заявки, согласование, передачу данных и отображение результата в личном кабинете.\n\nОтдельно проверяют ограничения: пользователя без доступа к части ассортимента, организацию без заполненных условий, товар без изображения или документа, заявку с нестандартным составом и ошибку обмена. Такие сценарии показывают, где требуется понятное сообщение пользователю, а где нужно уточнить правила работы.\n\n## Часто задаваемые вопросы\n### Можно ли использовать обычную корзину для B2B-портала?\n\nДа, если оформление сводится к выбору товаров и передаче заявки менеджеру. Когда нужно согласование состава, прикрепление спецификации, выбор организации или запрос расчёта, корзину дополняют нужными сценариями либо используют другой механизм заявки.\n\n### Какие данные нужны для проектирования B2B-каталога?\n\nПонадобятся примеры товарных групп и карточек, перечень параметров, правила отображения вариантов, документы, роли пользователей и путь заявки. Также необходимо определить источники данных и ответственных за их актуальность.\n\n### Можно ли ограничить ассортимент для отдельных клиентов?\n\nДа, если правила доступа определены заранее. Нужно описать, какая группа пользователей видит ассортимент, от чего зависит доступ и как обрабатываются новые организации или изменения их статуса.\n\n### Чем личный кабинет B2B отличается от обычной регистрации на сайте?\n\nЛичный кабинет B2B связан не только с сотрудником, но и с организацией, подразделением или условиями взаимодействия. Поэтому при проектировании определяют роли, видимость заявок и порядок подтверждения полномочий, а не только поля регистрационной формы.\n\n### Что проверить перед передачей портала в работу?\n\nПроверяют реальные товары и нестандартные ситуации: неполные карточки, варианты товара, ограниченный доступ, заявку без обязательного параметра, повторное оформление и ошибку передачи данных. Отдельно оценивают, понятны ли пользователю причины недоступности действия или необходимости уточнения заявки.","\u003Cp>Закупщик находит нужную позицию в каталоге, но не понимает, доступна ли она его организации, можно ли включить её в заявку и требуется ли внутреннее согласование. Менеджер получает обращение без реквизитов, спецификации или состава заказа. Каталог при этом существует, однако условия приходится уточнять в переписке и таблицах.\u003C\u002Fp>\n\u003Cp>Разработка B2B-портала с каталогом начинается с описания закупочного процесса. На одной площадке могут работать сотрудники разных компаний, подразделения одного клиента, дилеры, сервисные партнёры и сотрудники поставщика. Для каждой группы определяют доступ к товарам, данным и действиям.\u003C\u002Fp>\n\u003Ch2>B2B-портал и интернет-магазин: различия в оформлении заказа\u003C\u002Fh2>\n\u003Cp>Обычный интернет-магазин рассчитан на самостоятельное оформление: посетитель выбирает товар, добавляет его в корзину, оставляет контактные данные и передаёт заказ в обработку. Для большинства посетителей сценарий одинаков.\u003C\u002Fp>\n\u003Cp>В B2B-портале товар может быть частью заявки. Пользователь собирает позиции для расчёта, прикладывает техническое задание, указывает объект поставки или выбирает организацию. Заявка может проходить внутреннее согласование и проверку со стороны поставщика.\u003C\u002Fp>\n\u003Cp>До проектирования полезно зафиксировать маршрут заявки: кто ищет товар, кто формирует состав, кто согласует его у клиента, какие сведения получает поставщик и что происходит после отправки. Иначе корзина и форма заказа останутся интерфейсом для ручной обработки.\u003C\u002Fp>\n\u003Ch2>Структура каталога и состав товарных данных\u003C\u002Fh2>\n\u003Cp>Каталог должен помогать закупщику и техническому специалисту сопоставить позицию со своей задачей: сравнить варианты, открыть документы, добавить товар в заявку. Для сложного ассортимента недостаточно названия, изображения и краткого описания.\u003C\u002Fp>\n\u003Cp>Категории строят с учётом реального поиска. Навигация может опираться на тип оборудования, область применения, совместимость или производителя. Одна позиция иногда относится к нескольким разделам, поэтому правила размещения нужно определить заранее.\u003C\u002Fp>\n\u003Cp>Для каждого типа товара задают набор полей: параметры, варианты исполнения, единицы измерения, файлы, связанные позиции и признаки доступности. Фильтры дают предсказуемый результат, когда значения заполняются по единым правилам. Если одно и то же свойство вносится в свободной форме или отсутствует в части карточек, выдача становится неполной.\u003C\u002Fp>\n\u003Ch2>Личный кабинет и роли пользователей\u003C\u002Fh2>\n\u003Cp>Один контрагент нередко представлен несколькими сотрудниками. Закупщик готовит заявку, руководитель согласует её, бухгалтер работает с документами, а технический специалист проверяет параметры. Этим пользователям не требуется одинаковый набор прав.\u003C\u002Fp>\n\u003Cp>В требованиях отдельно описывают роли и границы видимости. Важно определить, видит ли сотрудник заявки коллег, имеет ли доступ к истории обращений организации, может ли менять реквизиты и адреса или только создавать черновик.\u003C\u002Fp>\n\u003Cp>Отдельно предусматривают изменение состава пользователей: увольнение, перевод в другое подразделение, ошибочное назначение роли. Данные сотрудника и данные организации не стоит объединять в одной модели без правил доступа. Контактное лицо, договор, адрес поставки и условия оформления относятся к разным сущностям и могут иметь разные ограничения видимости.\u003C\u002Fp>\n\u003Ch2>Доступ к ассортименту и правила оформления заявок\u003C\u002Fh2>\n\u003Cp>Разным группам пользователей может быть доступен разный ассортимент и разные способы оформления. Такие правила не стоит оставлять только в программной логике. До разработки определяют, от каких признаков зависит отображение товара, где хранится источник данных и кто поддерживает сведения в актуальном состоянии.\u003C\u002Fp>\n\u003Cp>Для товаров, которые нельзя оформить по стандартному сценарию, предусматривают отдельный маршрут: запрос на расчёт, сбор спецификации или передача заявки менеджеру. Пользователь должен понимать, что именно передаётся: отдельная позиция, набор товаров, проектная потребность или повторный заказ по ранее согласованному составу.\u003C\u002Fp>\n\u003Cp>При тестировании проверяют исключения: организацию без назначенных условий, товар с неполными данными, изменившийся статус позиции, несколько условий для одной компании. Такие ситуации стоит предусмотреть ещё на этапе проектирования и тестирования.\u003C\u002Fp>\n\u003Ch2>Интеграции B2B-портала и обмен данными\u003C\u002Fh2>\n\u003Cp>Формулировка «нужна интеграция с учётной системой» не определяет состав работ. Для портала перечисляют объекты обмена и действия, в которых они участвуют: товары, параметры, статусы заявок, реквизиты организаций, документы, история заказов.\u003C\u002Fp>\n\u003Cp>Для каждого объекта определяют источник данных, направление передачи и правило сопоставления идентификаторов. Также заранее решают, что происходит при ошибке: где она фиксируется, кто разбирает проблему, можно ли повторить передачу и как обрабатываются неполные сведения. Иначе товар может появиться без обязательных полей, а заявка — без связи с нужной организацией.\u003C\u002Fp>\n\u003Cp>«1С-Битрикс: Управление сайтом» может использоваться для публичной части портала и личного кабинета в рамках настроенного проекта. CMS не заменяет процессы обработки заявок и не определяет, кто принимает решение по ним.\u003C\u002Fp>\n\u003Ch2>Как определить границы разработки\u003C\u002Fh2>\n\u003Cp>При выборе подхода оценивают не только перечень экранов, но и рабочие сценарии. Каталог, карточка товара и личный кабинет могут выглядеть похоже, но отличаться правилами доступа к ассортименту, составом заявки, согласованием, документами и обменом данными.\u003C\u002Fp>\n\u003Cp>До начала работ нужны реальные примеры: обычные товары, позиции с вариантами, карточки с неполными данными, товары под запрос и повторные заказы. На таких примерах проще проверить структуру каталога, фильтры, права пользователей и логику оформления.\u003C\u002Fp>\n\u003Cp>С подрядчиком важно согласовать границы решения: какие сценарии входят в проект, какие данные предоставляет заказчик, кто поддерживает каталог и какие условия требуют отдельного описания. Это помогает избежать ситуации, когда слово «портал» по-разному понимают участники проекта.\u003C\u002Fp>\n\u003Ch2>Проверка B2B-каталога перед запуском\u003C\u002Fh2>\n\u003Cp>Тестирование не сводится к просмотру карточек на тестовых данных. Проверяют путь каждого типа пользователя: поиск, фильтрацию, выбор варианта, формирование заявки, согласование, передачу данных и отображение результата в личном кабинете.\u003C\u002Fp>\n\u003Cp>Отдельно проверяют ограничения: пользователя без доступа к части ассортимента, организацию без заполненных условий, товар без изображения или документа, заявку с нестандартным составом и ошибку обмена. Такие сценарии показывают, где требуется понятное сообщение пользователю, а где нужно уточнить правила работы.\u003C\u002Fp>\n\u003Ch2>Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Ch3>Можно ли использовать обычную корзину для B2B-портала?\u003C\u002Fh3>\n\u003Cp>Да, если оформление сводится к выбору товаров и передаче заявки менеджеру. Когда нужно согласование состава, прикрепление спецификации, выбор организации или запрос расчёта, корзину дополняют нужными сценариями либо используют другой механизм заявки.\u003C\u002Fp>\n\u003Ch3>Какие данные нужны для проектирования B2B-каталога?\u003C\u002Fh3>\n\u003Cp>Понадобятся примеры товарных групп и карточек, перечень параметров, правила отображения вариантов, документы, роли пользователей и путь заявки. Также необходимо определить источники данных и ответственных за их актуальность.\u003C\u002Fp>\n\u003Ch3>Можно ли ограничить ассортимент для отдельных клиентов?\u003C\u002Fh3>\n\u003Cp>Да, если правила доступа определены заранее. Нужно описать, какая группа пользователей видит ассортимент, от чего зависит доступ и как обрабатываются новые организации или изменения их статуса.\u003C\u002Fp>\n\u003Ch3>Чем личный кабинет B2B отличается от обычной регистрации на сайте?\u003C\u002Fh3>\n\u003Cp>Личный кабинет B2B связан не только с сотрудником, но и с организацией, подразделением или условиями взаимодействия. Поэтому при проектировании определяют роли, видимость заявок и порядок подтверждения полномочий, а не только поля регистрационной формы.\u003C\u002Fp>\n\u003Ch3>Что проверить перед передачей портала в работу?\u003C\u002Fh3>\n\u003Cp>Проверяют реальные товары и нестандартные ситуации: неполные карточки, варианты товара, ограниченный доступ, заявку без обязательного параметра, повторное оформление и ошибку передачи данных. Отдельно оценивают, понятны ли пользователю причины недоступности действия или необходимости уточнения заявки.\u003C\u002Fp>\n"]