B2B-портал для оптовых продаж: личный кабинет, остатки и цены под клиента

B2B-портал — это отдельный контур для оптовых продаж: каждый клиент входит под своей учётной записью, видит согласованные с ним цены и доступные остатки, оформляет заказ и получает документы без переписки с менеджером. Такой портал не заменяет розничную витрину и не сводится к ней: он строится вокруг договора, ролей и учётных данных. Ниже — что именно определяет работу B2B-портала, как связать его с 1С, какие развилки возникают при внедрении и как проверить результат до запуска.

Что такое B2B-портал и какую задачу он закрывает

B2B-портал — это веб-система, через которую оптовый покупатель самостоятельно работает с поставщиком: смотрит ассортимент под свои условия, проверяет доступность товара, оформляет и повторяет заказы, получает счета и закрывающие документы. Ключевое отличие от обычного интернет-магазина в том, что портал обслуживает не анонимный поток покупателей, а ограниченный круг компаний с договорами.

Задача, которую решает B2B-портал, формулируется через издержки. Пока оптовые заказы идут по почте, телефону и в мессенджерах, менеджер вручную уточняет цену, проверяет остаток, собирает заявку, выставляет счёт и отправляет документы. Чем больше постоянных клиентов, тем больше таких операций и тем меньше времени остаётся на привлечение новых. Портал переводит повторяющуюся часть в самообслуживание.

Второй слой задачи — доверие к данным. Оптовый клиент планирует закупку заранее и не готов ждать ответа «уточним наличие». Если портал показывает цену и остаток, которые расходятся с реальностью, им перестают пользоваться, и продажи возвращаются в ручной режим. Поэтому B2B-портал — это в первую очередь проект про данные и процессы, и только потом про интерфейс.

Третий слой — управляемость. Когда заказы, цены и документы проходят через один контур, у руководителя появляется единая картина: кто из клиентов заказывает, что именно, с какой периодичностью и где возникают задержки. Без портала эти сведения разбросаны по почтовым ящикам и записям менеджеров.

Чем B2B-портал отличается от розничного магазина

Различия не косметические, они определяют архитектуру. Розничная витрина рассчитана на то, что все покупатели равны, а опт строится на индивидуальных условиях.

• Цены. В рознице одна цена для всех. В опте цена зависит от договора, объёма, категории клиента, действующих акций. Один и тот же товар может стоить по-разному для разных покупателей.
• Доступ. Розничная витрина открыта всем. Оптовый портал закрыт: вход по учётной записи, привязка к компании и договору.
• Оплата. В рознице — предоплата картой. В опте — отсрочка, лимит задолженности, оплата по счёту, взаимозачёты.
• Документы. Розничному покупателю нужен чек. Оптовому — счёт, накладная, счёт-фактура, акт, УПД.
• Роли. У оптового клиента несколько сотрудников: закупщик, согласующий, бухгалтер. У них разные права и разные задачи.
• Повторяемость. Опт закупается регулярно по похожему списку. Повторный заказ — основной сценарий, а не исключение.

Из этого следует практический вывод: попытка вести опт на розничной витрине с единым прайсом рано или поздно упирается в ручную работу. Менеджеры всё равно пересчитывают цены, проверяют остатки и собирают заказы в учётной системе. Портал нужен именно там, где эти операции повторяются и поддаются формализации.

Какие данные определяют работу B2B-портала

Портал не хранит истину в себе — он показывает то, что приходит из учётной системы и настроек. Поэтому до проектирования интерфейса нужно разобраться с тремя группами данных: цены, остатки и клиенты.

Типы цен и правила доступа

В ранних версиях платформы описывался подход, при котором в каталоге можно завести несколько типов цен и для каждого задать права доступа — какие пользователи могут покупать по этой цене. Там же отмечалось, что можно разрешить просмотр нескольких ценовых колонок, но покупку — только по доступной. Этот принцип полезно взять за ориентир, но конкретные возможности платформы нужно проверять на актуальной версии продукта и в документации.

На практике важно ответить на вопросы: сколько ценовых колонок существует, кто их назначает, как часто они меняются, что происходит при смене условий договора. Если цена назначается вручную менеджером в учётной системе, портал должен получать уже готовый результат, а не пытаться рассчитать его самостоятельно.

Остатки и доступность к отгрузке

Остаток на складе и доступность к отгрузке — не одно и то же. Часть товара может быть зарезервирована под другие заказы, часть — в пути, часть — на удалённом складе. Если портал показывает только общий остаток, клиент оформляет заказ на то, что фактически недоступно, и получает отказ.

Поэтому нужно заранее определить, какой именно показатель выводится покупателю: свободный остаток, доступный к отгрузке, или ожидаемое поступление с датой. Это решение принимается вместе с ответственными за склад и учёт, а не только на стороне веб-разработки.

Клиенты, договоры и юридические лица

Известно, что один пользователь может работать под разными юридическими лицами, и для этого используются профили покупателя. Потребность реальная: у оптового клиента нередко несколько компаний, и закупщик переключается между ними. Проверять, как это реализовано в актуальной версии платформы, следует по документации.

Отдельно фиксируется, к какому договору привязан клиент, какая у него отсрочка, какой лимит и кто со стороны поставщика отвечает за условия. Эти данные — входные для портала, а не то, что он придумывает сам.

Роли и доступы: кто что видит в B2B-портале

Оптовый клиент — это не один человек, а группа сотрудников с разными правами. Типовой набор ролей выглядит так: закупщик формирует заказ, согласующий подтверждает его, бухгалтер работает с документами, руководитель смотрит сводку. Если всем выдать одинаковые права, портал теряет смысл как инструмент контроля.

Со стороны поставщика тоже есть роли: менеджер клиента, оператор заказов, бухгалтерия, администратор портала. Каждая роль должна видеть только то, что ей нужно. Это не только вопрос удобства, но и вопрос разграничения доступа к коммерческим условиям.

Практический шаг — составить матрицу «роль — действие» до начала разработки. В ней перечисляются действия: просмотр цены, оформление заказа, подтверждение, скачивание документа, изменение реквизитов. Матрица становится основой для настройки прав и для приёмочных проверок.

Интеграция с 1С: что и как связывается

B2B-портал без связи с учётной системой быстро теряет доверие: цены и остатки устаревают, заказы приходится переносить вручную. Поэтому интеграция — не дополнительная опция, а часть ядра проекта.

Направления обмена

Обмен обычно идёт в двух направлениях. Из учётной системы в портал поступают номенклатура, цены, остатки, условия по клиентам. Из портала в учётную систему уходят заказы и, при необходимости, заявки на документы. Конкретные механизмы обмена зависят от версии и конфигурации систем, поэтому их состав и ограничения нужно уточнять у специалистов, которые сопровождают вашу 1С.

Интеграция с внешними системами обычно осуществляется через веб-сервисы и обмен файлами. Это описание подхода, а не гарантия того, что в вашей конфигурации всё заработает так же. Способ проверки простой: составить перечень полей, которые должны совпадать, и сверить их на тестовом контуре.

Что делать, если данные в 1С не готовы

Частая ситуация: в учётной системе нет чёткого разделения цен по клиентам, остатки ведутся неаккуратно, а часть договоров существует только на бумаге. В этом случае начинать разработку портала рано — сначала наводится порядок в данных.

Разумная последовательность: описать текущие правила ценообразования, сверить их с тем, что фактически происходит, зафиксировать расхождения и только потом переносить логику в портал. Если этого не сделать, портал будет аккуратно показывать неверные данные.

Сравнение вариантов реализации

Выбор варианта зависит от масштаба опта, состояния учёта и готовности менять процессы. Ниже — сравнение типовых путей.

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

С чего начать внедрение

Первый шаг — не дизайн и не выбор платформы, а описание процесса продаж: как формируются цены, как считаются остатки, какие роли у клиента, что уже есть в учётной системе. По этому описанию видно, что можно автоматизировать сразу, а что требует наведения порядка в учёте.

Полезно начать с аудита текущего магазина или учётного контура: он показывает, какие данные уже пригодны, а какие придётся готовить. Как это устроено, разобрано в материале Аудит интернет-магазина — что проверяют и что будет в отчёте.

Если опт дополняет розницу, стоит заранее решить, будет ли это один контур с разными ролями или отдельные системы. Общие принципы описаны в статье про разработку интернет-магазина, а о том, из каких частей складывается бюджет, — в разборе Сколько стоит разработка интернет-магазина: из чего складывается цена.

Дальше проект разбивается на этапы. Разумно выделить пилот: одна группа клиентов, ограниченный набор функций, тестовый контур. Пилот позволяет проверить данные и процессы до того, как портал станет основным каналом заказов.

Учебный пример: оптовый поставщик переводит заказы в портал

Учебный пример. Данные условные и приведены для иллюстрации логики, а не как статистика.

Входные условия. Оптовая компания продаёт крепёж и инструмент. У неё около 120 постоянных клиентов, часть из них — группы из двух-трёх юридических лиц. Действуют четыре ценовые колонки: базовая, дилерская, партнёрская и специальная по отдельным договорам. Заказы принимают четыре менеджера: по телефону, почте и в мессенджерах. Учёт ведётся в 1С, остатки — по двум складам.

Проблема. Менеджеры тратят значительную часть дня на уточнение цен и остатков, повторные заказы оформляются вручную, документы отправляются по запросу. Клиенты жалуются, что не видят актуальное наличие.

Что сделали. Сначала описали правила ценообразования и сверили их с фактическими сделками. Обнаружили, что часть клиентов получает цены, не совпадающие с формально назначенной колонкой, — это зафиксировали и привели к единому правилу. Затем составили матрицу ролей: закупщик, согласующий, бухгалтер. Определили, что показывать клиенту: свободный остаток к отгрузке, а не общий. После этого запустили пилот на одной группе клиентов с ограниченным набором функций: вход, каталог с ценой клиента, остаток, оформление заказа, история и документы.

Как проверяли. Сравнили цены и остатки в портале с учётной системой на выборке позиций и клиентов. Провели несколько тестовых заказов от имени разных ролей и юрлиц. Сверили, что заказ из портала корректно попадает в учётную систему и что документы формируются по тем же реквизитам, что и раньше. Отдельно проверили поведение при смене цены и при нулевом остатке.

Наблюдаемый результат. Повторные заказы части клиентов пилотной группы стали оформляться через портал, менеджеры переключились на работу с новыми клиентами и сложными сделками. Точные показатели зависят от дисциплины данных и готовности клиентов, поэтому их нужно измерять на своём проекте, а не переносить из примера.

Ограничения примера. Компания небольшая, ассортимент и правила цен относительно простые. При нескольких десятках ценовых колонок, сложных согласованиях и нестабильном учёте объём подготовительной работы будет больше.

Как проверить решение перед запуском

Проверка строится вокруг данных и сценариев, а не вокруг внешнего вида. Ниже — применимый набор проверок.

• Цена для каждого тестового клиента совпадает с учётной системой на выбранной выборке позиций
• Остаток в портале соответствует доступному к отгрузке, а не общему
• Заказ из портала попадает в учётную систему без ручного переноса
• Документы формируются с корректными реквизитами юрлица
• Переключение между юрлицами одного клиента не смешивает историю и цены
• Роли видят только разрешённые действия
• Поведение при нулевом остатке и при смене цены описано и проверено
• Есть план возврата: как отключить портал и вернуться к прежнему приёму заказов
• Изменения внесены сначала на копии, затем на тестовом контуре, и только потом на рабочем
• Назначены ответственные за данные: цены, остатки, клиенты, документы

Отдельно стоит проверить, что происходит при сбое обмена: увидит ли клиент устаревшие данные и как это будет обозначено. Молчаливое устаревание опаснее явной ошибки.

Ограничения и типичные ошибки

Портал запускают раньше, чем готовы данные. Самая частая причина провала: цены и остатки в учётной системе не приведены к единым правилам, и портал транслирует этот беспорядок клиентам.

Пытаются закрыть все сценарии сразу. Согласования, лимиты, сложные акции, несколько валют — всё это увеличивает объём проекта. Пилот с ограниченным набором функций снижает риск.

Не описывают роли. Если права не разграничены, портал либо неудобен, либо открывает лишнее.

Забывают про возврат. Любое изменение в учётной системе и на портале должно иметь план отката: копия, резервирование, тест, возможность вернуться к прежнему режиму.

Смешивают розницу и опт без разграничения. Общий каталог удобен, но цены и права должны быть разделены явно.

Обещают эффект заранее. Влияние портала на продажи зависит от того, как клиенты готовы менять привычки, и от качества данных. Корректнее измерять результат на своём проекте, чем ориентироваться на чужие обещания.

Отдельная граница — документы и персональные данные. Состав документов, требования к их формированию и обработке данных клиентов нужно сверять с профильным специалистом; портал лишь отражает принятые в компании правила.