B2B-портал для оптовиков: цены, остатки, заказы, учёт

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

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

Чем оптовый заказ отличается от розничной корзины?

Попытка сделать B2B-портал «как интернет-магазин, только с оптовыми ценами» — самая частая причина провала. Розничная корзина и оптовый заказ — разные процессы с разной логикой, и различия определяют всё проектирование.

Из таблицы следуют три практических вывода. Первый: сердце портала — не каталог, а модель условий и ролей; каталог вторичен. Второй: заказ в B2B почти всегда проходит через согласование, поэтому проектируется не «купить», а «запросить — согласовать — выставить счёт — отгрузить — получить документы». Третий: портал не привлекает партнёров и не даёт трафика — он снимает ручную работу с существующей сетью и ограничение на её рост. На странице Like Sites это сказано прямо: обещать новых партнёров от закрытого контура нельзя — у него нет публичных страниц и поискового трафика (страница «Оптовый портал для дилеров», проверено 1 ноября 2026).

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

Какие роли нужны покупателю и менеджеру?

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

Матрица ролей — минимальный набор, который покрывает большинство оптовых компаний:

Правила, без которых матрица не работает:

1. Регистрация партнёра — с подтверждением. Самостоятельная регистрация создаёт только запрос; доступ открывается после проверки реквизитов и привязки к контрагенту в учёте ответственным сотрудником.
2. Один контрагент — одна организация в портале с несколькими пользователями. Пользователь привязан к организации; условия применяются к организации, а не к пользователю.
3. Отзыв доступа — немедленный и процедурный. Порядок и ответственные фиксируются заранее, иначе доступы накапливаются и перестают соответствовать составу партнёров.
4. Изоляция данных проверяется прямым обращением. Запрос чужого заказа или документа по адресу должен отклоняться — это пункт приёмки, а не пожелание.
5. Закрытый контур не индексируется и не попадает в карту сайта.
6. Менеджер видит партнёров своей зоны. Если зоны не разделены, это решение компании, принятое осознанно.

Страница Like Sites выносит безопасность доступа отдельным модулем и отдельным этапом проверки: изоляция данных, ограничение сессий, отзыв доступа, закрытие от поисковых систем, с проверкой готовности «попытка обратиться к данным другого партнёра отклоняется; закрытые страницы не индексируются» (страница «Оптовый портал для дилеров»). Утечка коммерческих условий обходится дороже любой другой ошибки портала.

Как показывать договорные цены?

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

Модель условий, которую нужно описать до реализации:

Правила отображения:

• Цена показывается только авторизованному пользователю и только своя. Неавторизованный посетитель не видит оптовых цен вовсе — ни «от», ни диапазонов. Если нужна публичная часть, это другой тип сайта.
• Приоритет применяется в системе, а не в голове менеджера. Если у партнёра есть индивидуальная цена на позицию, она перекрывает групповую; если нет — применяется групповая; если нет и её — базовая оптовая. Это проверяется на контрольных партнёрах при сдаче.
• Цена в заказе фиксируется на момент согласования. Если условия изменились между оформлением и согласованием, менеджер видит расхождение и принимает решение, а не портал молча пересчитывает.
• Источник актуальных значений один. Изменение цены в учёте доходит до портала в согласованный интервал, обратного направления нет: портал не редактирует цены.

Если персональные цены сейчас существуют только в файлах, первый шаг проекта — приведение их в учётную систему, и это работа компании, а не интегратора. Страница Like Sites называет это ключевым ограничением: возможности портала определяются тем, что доступно в учёте (страница «Оптовый портал для дилеров»). Как типы цен и соглашения устроены в вашей конфигурации 1С и как их отдавать на сайт — вопрос обмена с учётом, разобранный на странице интеграция интернет-магазина с 1С.

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

Как учитывать упаковки, кратность и минимальные партии?

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

Данные, которые нужны по каждой позиции:

Правила поведения:

1. Проверка — при добавлении в заказ и при отправке. Партнёр видит нарушение сразу, с понятным сообщением: не «ошибка», а «кратность 12, доступно 36 или 48».
2. Заказ с нарушением не отправляется. Это пункт приёмки: заказ с нарушением минимальной партии или кратности не уходит, сообщение понятно.
3. Исключения — через менеджера. Если партнёру разрешена некратная партия по договорённости, это делается на согласовании, а не отключением проверки для всех.
4. Остаток показывается в единицах продажи. «В наличии 14 коробов» понятнее партнёру, чем «168 шт.», но в учёт уходит базовая единица.
5. Повтор закупки пересчитывает кратность. Если за время с прошлого заказа кратность изменилась, повтор показывает это явно.

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

Как организовать наличие, резерв и предзаказ?

Партнёру нужно знать не «есть или нет», а сколько можно отгрузить и когда. У оптового наличия больше состояний, чем у розничного, и каждое требует решения компании.

Решения, которые принимает компания до настройки:

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

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

Как согласовывать заказ и выставлять счёт?

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

1. Партнёр собирает заказ. Из своей матрицы, в единицах продажи, с проверкой кратности и минимумов, по своим ценам. Видит предварительную сумму, доступность по позициям, сроки.
2. Партнёр отправляет заявку. Если роли разделены — сотрудник отправляет на утверждение внутри своей организации, утверждающий подтверждает. Заявка получает номер и статус «на согласовании».
3. Заявка приходит ответственному менеджеру. В CRM или в учёт — с полным составом, реквизитами, условиями и ссылкой на кабинет партнёра. Менеджер получает уведомление и задачу.
4. Менеджер согласует. Проверяет наличие под отгрузку, сроки, лимит и дебиторскую задолженность партнёра, исключения. Корректирует состав по договорённости — и партнёр видит изменения в кабинете с пометкой. Или отклоняет с причиной.
5. Заказ создаётся в учёте. Согласованная заявка становится заказом покупателя в 1С или МоемСкладе с реквизитами партнёра, договором, ценами и резервом по правилу.
6. Счёт формируется в учёте. Счёт на оплату выставляется учётной системой из заказа и появляется в кабинете партнёра как документ. Портал счёт не формирует — он его показывает. При отсрочке по договору шаг не блокирует отгрузку.
7. Оплата — по счёту или по отсрочке. Факт оплаты отражается в учёте бухгалтером по выписке или банковской интеграцией; портал получает статус.
8. Отгрузка. Документ отгрузки в учёте; статус и документы — в кабинет.
9. Закрывающие документы. Накладная или УПД, акт — из учёта в кабинет.

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

Что делает менеджер, а что система, — разделение, ради которого портал и строится:

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

Какие документы нужны в кабинете?

Запросы «пришлите счёт», «нужна накладная за март», «акт сверки за квартал» — заметная часть обращений к менеджерам, не связанная с продажей. Кабинет снимает их, если документы в нём есть и они свои.

Границы, которые страница Like Sites называет прямо: портал отображает документы, но не формирует их и не заменяет электронный документооборот; документы создаются в учётной или бухгалтерской системе, портал даёт доступ к тем из них, которые эта система предоставляет или которые загружает компания (страница «Оптовый портал для дилеров»). Какие реквизиты обязательны в счёте, накладной и УПД и в каком виде их можно отдавать партнёру — определяет бухгалтер по актуальным требованиям; портал не меняет содержание документов.

Правила доступа к документам: партнёр видит только свои; документ привязан к заказу или к периоду; выгрузка работает; доступ к документу по прямому адресу проверяется на принадлежность. Это пункты приёмки.

Минимальный состав для первого этапа — счёт и закрывающие документы по заказам. Акты сверки, договоры и расширенные документы — второй этап, если учёт их отдаёт.

Как связать портал с учётной системой?

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

Потоки данных между порталом и учётом:

Технически способ обмена зависит от конфигурации: штатный обмен с сайтом, стандартный интерфейс, HTTP-сервисы конфигурации или промежуточный сервис для 1С; JSON API с лимитами и вебхуками для МоегоСклада. Что доступно и какие права нужны — выясняется обследованием конкретной базы; подробно устройство обмена разобрано на странице интеграция интернет-магазина с 1С и на странице интеграция с МоимСкладом. Для портала важны три специфических момента.

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

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

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

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

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

Как перенести повторные заказы из почты и Excel?

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

Сценарий повторной закупки по шагам:

1. Партнёр открывает историю заказов и выбирает прошлый заказ или сохранённый регулярный список.
2. Система собирает новый заказ из тех же позиций и количеств в единицах продажи.
3. Пересчитывает по текущим ценам партнёра и показывает, что изменилось: цена, кратность, упаковка.
4. Проверяет наличие и матрицу: недоступные позиции помечены явно, не удалены молча и не заменены на аналог.
5. Проверяет кратность и минимумы с подсказками.
6. Партнёр правит количества, убирает или добавляет позиции, сохраняет список как регулярный, если нужно.
7. Отправляет на согласование — дальше обычный путь заказа.

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

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

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

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

Как принять первый этап?

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

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

Чек-лист приёмки первого этапа:

1. Модель доступа и правила выдачи прав зафиксированы документально.
2. Партнёр входит только в свой кабинет и видит только свои условия, цены, ассортимент и заказы.
3. Попытка обратиться к данным другого партнёра отклоняется, в том числе по прямому адресу.
4. Отзыв доступа немедленно прекращает работу партнёра.
5. Закрытые страницы не индексируются и не попадают в карту сайта.
6. Для контрольных партнёров условия соответствуют учётным данным; приоритет индивидуальных над групповыми применён верно.
7. Недоступная партнёру позиция не отображается и не может попасть в заказ.
8. Заказ с нарушением минимальной партии или кратности не отправляется; сообщение понятно.
9. Корректный заказ доходит до ответственного менеджера с полным набором полей и реквизитов и создаёт заказ в учёте один раз.
10. Изменение условий и остатков в учёте доходит до портала в согласованный интервал.
11. Повторная отправка заявки не создаёт дубль.
12. Неавторизованный посетитель не видит ни цен, ни матрицы, ни каталога.

Пункты 11–12 — стандартные для любой интеграции, остальные специфичны для закрытого контура. Протокол с датой хранится у ответственного за портал; при первом инциденте он показывает, был ли сценарий в проверке.

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

Когда портал не нужен?

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

• Партнёров мало и закупки нерегулярны. Несколько партнёров с редкими заказами обслуживаются менеджером быстрее, чем настраивается портал; ручная работа невелика, и снимать нечего.
• Условия не формализованы. Если цены и скидки существуют как договорённости в голове менеджера и меняются от сделки к сделке, в систему их не положить; сначала политика условий, затем портал.
• Учёт не отдаёт данных. Нет типов цен по контрагентам, нет упаковок и кратности, нет резервов — портал будет работать на копии данных, которую придётся поддерживать вручную. Сначала учёт.
• Нужна публичная розница. Если розничные продажи важны и должны остаться открытыми, нужен магазин с оптовым контуром поверх общего каталога, а не закрытый портал — другой тип сайта с другой экономикой.
• Главная задача — прямые продажи бренда, а дилеры второстепенны. Это сценарий магазина производителя с дилерским контуром через роли, а не отдельного портала.
• Нужно только показать прайс. Витрина с оптовыми ценами по запросу доступа — не портал; если ручной обработки заявок снимать не нужно, портал избыточен.
• Некому управлять доступами. Выдача, подтверждение и отзыв доступов — процесс компании; без ответственного доступы перестанут соответствовать составу партнёров, и закрытый контур станет открытым.
• Ожидание — новые партнёры. Портал их не приводит: у закрытого контура нет публичных страниц и поискового трафика; привлечение — задача публичной части сайта.

Страница Like Sites перечисляет часть этих границ прямо — «когда точнее подойдёт другая страница»: розница тоже нужна — магазин B2B + B2C; главная задача прямые продажи бренда — магазин для производителя; основной запрос — обмен с 1С; нужна прежде всего CRM и работа с заявками — интеграция с CRM (страница «Оптовый портал для дилеров»).

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

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