[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f2gm7rj0b7i8ss":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-internet-magazina-tseny-roli-i-soglasovanie-zakaza","Разработка B2B-интернет-магазина: роли и согласование",true,"2024-07-17T10:00:00+03:00","2026-09-06T16:09:26.499Z","Статьи","Корпоративная закупка требует понятных ролей и маршрута согласования. В статье разобраны права доступа, состав заявки и обмен данными.","\u002Fcontent-media\u002Farticles\u002Frazrabotka-b2b-internet-magazina-tseny-roli-i-soglasovanie-zakaza\u002Fassets\u002F3501a1718687.webp",[],"lc_50f4367fd4b7fc80b67a018a6db31a3a","Корпоративный покупатель выбирает товары в каталоге, но ему также важно понимать, доступен ли товар его организации, кто вправе сформировать заказ и кому предстоит его подтвердить. Сотруднику поставщика нужен состав заявки, реквизиты организации и комментарии к поставке.\n\nРазработка B2B-интернет-магазина начинается с правил работы: кто входит в личный кабинет, какие товары видит, кто формирует заказ и кто его согласует. Интерфейс должен отражать эти правила и маршрут обработки заявки.\n\n## B2B-интернет-магазин и сценарий корпоративной закупки\n\nВ розничной покупке один пользователь выбирает товар, указывает данные и оформляет заказ. В корпоративной закупке участвуют несколько сотрудников: закупщик формирует заказ, согласующий проверяет его, сотрудник поставщика уточняет условия, а получатель принимает поставку.\n\nСценарии для разных типов заказов до начала проектирования определяет рабочая группа заказчика и аналитик. Часть ассортимента может переходить в заявку сразу. Для товаров с переменными параметрами, нестандартной комплектацией или ограниченной доступностью предусматривают запрос на подтверждение. Без такого описания в корзине появляются действия, для которых не определён дальнейший процесс.\n\nПосле каждого действия покупателя фиксируют изменение статуса: кому поступает заказ, когда он возвращается на уточнение и в каком случае ожидает решения согласующего. Эти правила относятся к процессу продажи и не зависят от выбора CMS.\n\n## Состав заявки и доступ к товарам\n\nПравило доступа к товару нужно описать точнее, чем фразой «доступно для организации». В проекте определяют, какие данные связывают пользователя с организацией, какие группы товаров доступны сотрудникам и что происходит, если товар нельзя добавить в заказ.\n\nВ проектной документации фиксируют:\n\n- кто поддерживает актуальность данных о товарах;\n- какие данные связывают пользователя с организацией;\n- может ли сотрудник просматривать каталог без права оформить заказ;\n- как работает магазин, если товар недоступен для конкретной организации;\n- какие сведения должны сохраниться в составе заказа.\n\nНе каждый товар можно оформить по одному сценарию. Иногда каталог используют для подготовки спецификации, а сотрудник поставщика подтверждает состав заявки после проверки. В таком случае интерфейс должен показывать покупателю следующий этап обработки.\n\n## Роли пользователей в личном кабинете B2B-магазина\n\nЛичный кабинет организации не сводится к одной учётной записи для всех сотрудников. При общем доступе невозможно установить, кто создал заказ, изменил состав или подтвердил заявку. Набор ролей определяется процессом закупки, но обычно в нём есть сотрудник, формирующий заказ, согласующий и администратор со стороны покупателя.\n\nДля каждой роли команда проекта описывает доступные действия. Закупщик может просматривать каталог, создавать черновики и отправлять их на согласование. Согласующий открывает состав заказа, добавляет комментарий, подтверждает или отклоняет заявку. Администратор организации управляет пользователями в пределах согласованных полномочий.\n\nОтдельно описывают работу сотрудника поставщика: подтверждение состава, изменение статуса, добавление документов и комментариев. У покупателя и поставщика разные зоны ответственности, поэтому одинаковый набор прав для них не подходит.\n\n## Согласование заказа между сотрудниками покупателя\n\nСогласование превращает корзину в документ с определённым маршрутом проверок. Команда проекта описывает момент, когда заказ перестаёт быть черновиком, правила его изменения после отправки и действия при возврате на доработку.\n\nМаршрут может применяться ко всем заказам, отдельным организациям или заявкам с заданными условиями. В одном случае достаточно решения одного согласующего, в другом требуется последовательность проверок несколькими участниками. Сначала описывают маршрут согласования, затем выбирают техническое решение.\n\nПри возврате заказа покупатель видит причину, состав изменений и актуальную версию заказа. Если после согласования меняются количество или способ получения, в правилах процесса фиксируют необходимость повторного подтверждения и получателя уведомления.\n\n## Каталог и карточка товара для корпоративного покупателя\n\nB2B-каталог помогает собрать повторяющуюся закупку и проверить технические параметры. Покупателю могут потребоваться артикул, характеристики, варианты исполнения, кратность заказа, документы, совместимые позиции и сведения о доступности. Состав карточки определяет реальный ассортимент.\n\nДля проверки карточек берут несколько непохожих позиций: типовой товар, товар с вариантами, товар под заказ, позицию без изображения и товар с неполными характеристиками. На этих данных проверяют фильтры, поиск, сравнение, добавление в заказ и ограничения доступа.\n\nРеальный каталог может содержать пустые характеристики, варианты товара, позиции без изображения, разные единицы измерения и отдельные правила доступа. Если тестовые карточки заполнены одинаково, эти ситуации не попадают в проверку и проявляются при загрузке каталога.\n\nЕсли магазин работает на «1С-Битрикс: Управление сайтом», CMS используют для публичной части, каталога и контента. Процессы сотрудников, обработку заявок и правила обмена данными описывают отдельно: CMS сайта не заменяет CRM и регламент работы компании.\n\n## Интеграции и обмен данными в B2B-продаже\n\nТребование «синхронизировать всё» не содержит данных для постановки задачи. Чтобы передать задачу в разработку, заказчик и аналитик перечисляют объекты обмена, направления передачи, расписание обновлений и правила обработки ошибок.\n\nДля каталога отдельно описывают товары, характеристики, остатки и изображения. Для заказа — состав, данные организации, комментарии, выбранный способ получения и статусы, если их передают в другую систему. При нескольких источниках для каждого типа данных назначают исходную систему и порядок действий при расхождении.\n\nВ проекте также фиксируют ограничения: какие товары доступны к заказу, какие данные покупатель может редактировать на сайте и какие изменения проверяет сотрудник. Такие правила помогают отделить ошибку обмена от предусмотренного ограничения процесса.\n\n## Как оценивать разработку B2B-интернет-магазина\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### Чем B2B-магазин отличается от обычного интернет-магазина?\n\nРазличие связано с порядком корпоративной закупки. B2B-магазин учитывает организацию покупателя, роли сотрудников, права доступа, согласование и дальнейшую обработку заявки. Каталог и корзина остаются частью интерфейса, но не описывают весь процесс закупки.","\u003Cp>Корпоративный покупатель выбирает товары в каталоге, но ему также важно понимать, доступен ли товар его организации, кто вправе сформировать заказ и кому предстоит его подтвердить. Сотруднику поставщика нужен состав заявки, реквизиты организации и комментарии к поставке.\u003C\u002Fp>\n\u003Cp>Разработка B2B-интернет-магазина начинается с правил работы: кто входит в личный кабинет, какие товары видит, кто формирует заказ и кто его согласует. Интерфейс должен отражать эти правила и маршрут обработки заявки.\u003C\u002Fp>\n\u003Ch2>B2B-интернет-магазин и сценарий корпоративной закупки\u003C\u002Fh2>\n\u003Cp>В розничной покупке один пользователь выбирает товар, указывает данные и оформляет заказ. В корпоративной закупке участвуют несколько сотрудников: закупщик формирует заказ, согласующий проверяет его, сотрудник поставщика уточняет условия, а получатель принимает поставку.\u003C\u002Fp>\n\u003Cp>Сценарии для разных типов заказов до начала проектирования определяет рабочая группа заказчика и аналитик. Часть ассортимента может переходить в заявку сразу. Для товаров с переменными параметрами, нестандартной комплектацией или ограниченной доступностью предусматривают запрос на подтверждение. Без такого описания в корзине появляются действия, для которых не определён дальнейший процесс.\u003C\u002Fp>\n\u003Cp>После каждого действия покупателя фиксируют изменение статуса: кому поступает заказ, когда он возвращается на уточнение и в каком случае ожидает решения согласующего. Эти правила относятся к процессу продажи и не зависят от выбора CMS.\u003C\u002Fp>\n\u003Ch2>Состав заявки и доступ к товарам\u003C\u002Fh2>\n\u003Cp>Правило доступа к товару нужно описать точнее, чем фразой «доступно для организации». В проекте определяют, какие данные связывают пользователя с организацией, какие группы товаров доступны сотрудникам и что происходит, если товар нельзя добавить в заказ.\u003C\u002Fp>\n\u003Cp>В проектной документации фиксируют:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>кто поддерживает актуальность данных о товарах;\u003C\u002Fli>\n\u003Cli>какие данные связывают пользователя с организацией;\u003C\u002Fli>\n\u003Cli>может ли сотрудник просматривать каталог без права оформить заказ;\u003C\u002Fli>\n\u003Cli>как работает магазин, если товар недоступен для конкретной организации;\u003C\u002Fli>\n\u003Cli>какие сведения должны сохраниться в составе заказа.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Не каждый товар можно оформить по одному сценарию. Иногда каталог используют для подготовки спецификации, а сотрудник поставщика подтверждает состав заявки после проверки. В таком случае интерфейс должен показывать покупателю следующий этап обработки.\u003C\u002Fp>\n\u003Ch2>Роли пользователей в личном кабинете B2B-магазина\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>B2B-каталог помогает собрать повторяющуюся закупку и проверить технические параметры. Покупателю могут потребоваться артикул, характеристики, варианты исполнения, кратность заказа, документы, совместимые позиции и сведения о доступности. Состав карточки определяет реальный ассортимент.\u003C\u002Fp>\n\u003Cp>Для проверки карточек берут несколько непохожих позиций: типовой товар, товар с вариантами, товар под заказ, позицию без изображения и товар с неполными характеристиками. На этих данных проверяют фильтры, поиск, сравнение, добавление в заказ и ограничения доступа.\u003C\u002Fp>\n\u003Cp>Реальный каталог может содержать пустые характеристики, варианты товара, позиции без изображения, разные единицы измерения и отдельные правила доступа. Если тестовые карточки заполнены одинаково, эти ситуации не попадают в проверку и проявляются при загрузке каталога.\u003C\u002Fp>\n\u003Cp>Если магазин работает на «1С-Битрикс: Управление сайтом», CMS используют для публичной части, каталога и контента. Процессы сотрудников, обработку заявок и правила обмена данными описывают отдельно: CMS сайта не заменяет CRM и регламент работы компании.\u003C\u002Fp>\n\u003Ch2>Интеграции и обмен данными в B2B-продаже\u003C\u002Fh2>\n\u003Cp>Требование «синхронизировать всё» не содержит данных для постановки задачи. Чтобы передать задачу в разработку, заказчик и аналитик перечисляют объекты обмена, направления передачи, расписание обновлений и правила обработки ошибок.\u003C\u002Fp>\n\u003Cp>Для каталога отдельно описывают товары, характеристики, остатки и изображения. Для заказа — состав, данные организации, комментарии, выбранный способ получения и статусы, если их передают в другую систему. При нескольких источниках для каждого типа данных назначают исходную систему и порядок действий при расхождении.\u003C\u002Fp>\n\u003Cp>В проекте также фиксируют ограничения: какие товары доступны к заказу, какие данные покупатель может редактировать на сайте и какие изменения проверяет сотрудник. Такие правила помогают отделить ошибку обмена от предусмотренного ограничения процесса.\u003C\u002Fp>\n\u003Ch2>Как оценивать разработку B2B-интернет-магазина\u003C\u002Fh2>\n\u003Cp>Разработка B2B-интернет-магазина зависит не от числа страниц, а от согласованной модели работы. Два сайта с похожим каталогом различаются по составу задач, если в одном все покупатели оформляют заказы по единому сценарию, а в другом предусмотрены организации, роли, правила доступа, согласование и обмен с внешними системами.\u003C\u002Fp>\n\u003Cp>При обсуждении работ заказчик проверяет, как подрядчик описывает результат. Вопросы относятся к конкретным сценариям: кто создаёт пользователя, как определяется организация, что видит закупщик, как меняется заказ после отправки, где возникает ошибка обмена и кто её разбирает.\u003C\u002Fp>\n\u003Cp>Границы работ оформляют отдельно. Загрузка исходного каталога, подготовка фотографий и описаний, очистка старых данных, настройка исключений, инструкции для сотрудников и перенос исторических заказов относятся к разным задачам. Такое разделение помогает согласовать состав работ до начала разработки.\u003C\u002Fp>\n\u003Ch2>Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Ch3>Как ограничить доступ к товарам для разных организаций?\u003C\u002Fh3>\n\u003Cp>Сначала определяют, по какому признаку организация получает доступ к товару или группе товаров. Затем описывают источник этих данных, связь пользователя с организацией и поведение магазина, если доступ отсутствует. Проверку проводят на примерах реальных организаций и позиций каталога.\u003C\u002Fp>\n\u003Ch3>Можно ли отправить заказ на проверку до его обработки поставщиком?\u003C\u002Fh3>\n\u003Cp>Да, если процесс предусматривает внутреннее согласование или проверку состава заявки. Интерфейс должен показывать текущий этап, а внутренний регламент — назначать ответственного и правила перехода заказа между статусами.\u003C\u002Fp>\n\u003Ch3>Кто должен согласовывать заказ со стороны клиента?\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"]