Личный кабинет дилера с персональными ценами и остатками: как это устроено и зачем нужно

Дилер больше не звонит менеджеру за прайсом и наличием — он сам заходит в кабинет

В чём проблема и кому полезна статья

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

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

Что такое личный кабинет дилера с персональными ценами и остатками

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

Обычно личный кабинет дилера включает просмотр персонального каталога товаров, индивидуальные цены и скидки [2], а также, как правило, историю заказов, документы, статусы отгрузок и взаиморасчёты. Ключевое отличие от розничного интернет-магазина: доступ по логину — каталог и цены видны только авторизованным дилерам, а не всем посетителям сайта, и реальные остатки — наличие подтягивается из учётной системы, чтобы дилер не заказывал то, чего нет [1].

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

Как это работает технически

Источник данных: учётная система как единая точка правды

Практика, которая почти всегда себя оправдывает: номенклатура, цены и остатки ведутся в одном месте — учётной системе (1С:УТ, 1С:ERP, 1С:КА и подобных), а кабинет их только отображает. Номенклатура и остатки — «хозяин» 1С, сайт их только отображает; заказ рождается на сайте, но дальше живёт в учётной системе [4]. Если это правило нарушить и позволить заводить товары параллельно в двух системах, справочники быстро расходятся — частая ошибка B2B-проектов — считать портал вторым источником правды и заводить номенклатуру одновременно в 1С и на сайте вместо единого мастер-справочника [5].

Персональные цены: виды цен и соглашения в учётной системе

Технически персональная цена — это не просто «скидка в проценте», а результат применения к контрагенту определённого вида цены и условий соглашения. В типовых конфигурациях 1С скидки и наценки назначаются в зависимости от типа клиентов и условий продаж, закрепляются за группой клиентов через типовые соглашения либо за конкретным клиентом через индивидуальные соглашения [6].

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

Личному кабинету не нужно «изобретать» логику скидок заново — его задача правильно считать уже рассчитанную в учётной системе цену для конкретного авторизованного контрагента и корректно её отобразить. После авторизации система определяет организацию клиента и подставляет её цены в каталог, карточку товара, корзину и шаблоны заказов [8].

Разработчикам стоит помнить, что штатный обмен между учётной системой и сайтом не всегда «из коробки» умеет передавать именно индивидуальные условия — иногда это требует отдельной доработки: штатный обмен между 1С и сайтом не умеет передавать индивидуальные скидки, поэтому для этого нужен отдельный модуль, который автоматически выгружает условия договоров и скидки из 1С на портал [9], при этом приоритет скидок должен соответствовать логике учётной системы — позиционная скидка на конкретный товар имеет преимущество над общей скидкой на весь заказ [9].

Остатки, резервы и синхронизация

С остатками сложнее, чем с ценами, потому что они меняются в реальном времени, а не раз в день. Если кабинет обновляет данные по расписанию, а не мгновенно, возникает классическая проблема: товар уже зарезервирован в учётной системе, а на витрине он всё ещё показан как доступный, что приводит к конфликту с контрагентом и ручному пересогласованию заказа [10].

Именно поэтому многие современные дилерские порталы обновляют остатки не раз в сутки, а значительно чаще — например, каталог, персональные цены и остатки могут обновляться примерно раз в 10 минут двусторонним обменом, при этом сама учётная система остаётся в защищённой сети за периметром [11].

Отдельный вопрос — как трактовать «резерв». До появления понятия резерва в некоторых системах товар списывался сразу при оформлении заказа независимо от факта оплаты, из-за чего вести количественный учёт остатков было практически невозможно [12]; современный подход — держать отдельно «свободный остаток», «зарезервировано под заказ» и «в пути», и показывать дилеру именно свободный остаток с явным статусом резерва, а не единое число «сколько на складе».

Способы обмена данными: CommerceML, API, промежуточная база

Есть четыре основных способа связать 1С с сайтом: типовой обмен CommerceML, обмен через прямой API, промежуточная база данных и готовые модули-коннекторы [13]. У каждого свои плюсы и ограничения.

CommerceML — отраслевой стандарт, придуманный самой фирмой «1С». Инициатором обмена выступает система «1С:Предприятие»: устанавливается HTTP-соединение, система запрашивает у сайта параметры пакета и сжатия, после чего формирует и передаёт XML-сообщения [14]. Плюс — «из коробки» работает почти с любой типовой конфигурацией 1С без больших доработок. Минус — это, как правило, пакетный обмен по расписанию, а не мгновенная реакция на изменение.

Прямой REST API — более современный подход. При изменении цены в 1С система отправляет короткий запрос на сайт, и цена обновляется без полной перезагрузки всего каталога [15], что заметно снижает задержку по сравнению с пакетным CommerceML-обменом, но требует больше разработки с обеих сторон.

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

Независимо от способа, обмен обычно двусторонний: из учётной системы на сайт передаются изменения по товарам, разделам, ценам и остаткам, а обратно — заказы, как с сайта в 1С, так и наоборот [16].

Российская специфика

Несколько моментов, которые стоит учитывать именно в РФ.

Доминирование 1С как учётной системы. Запрос «интеграция 1С» — один из самых востребованных в российском IT, поскольку 1С установлена в 83% российских компаний, при этом сайт есть почти у всех, а связать их — задача, которую регулярно недооценивают [13]. Поэтому для большинства российских дилерских кабинетов вопрос звучит не «с какой ERP интегрироваться», а «как именно организовать обмен с уже стоящей 1С».

Готовые протоколы и модули под 1С. CommerceML разрабатывался и развивается совместно фирмами «1С» и «1С-Битрикс», поэтому для типовых конфигураций 1С:УТ, 1С:ERP, 1С:КА обмен с сайтом обычно включён как штатный функционал — не нужно писать интеграцию с нуля, но часто требуется доработка под нетиповые сценарии (например, передачу именно индивидуальных, а не типовых цен).

Требования к защите персональных данных. Хотя личный кабинет дилера технически работает с юридическими лицами, в системе всё равно хранятся персональные данные конкретных сотрудников контрагента (ФИО, телефон, email контактного лица), поэтому при передаче таких данных нужно учитывать требования 152-ФЗ: шифрование данных особенно важно при передаче персональных данных в соответствии с ФЗ-152 [17]. На практике это означает минимум HTTPS-канал, ограничение состава передаваемых персональных полей и политику хранения логов с такими данными.

ЭДО и маркировка. Для многих оптовых отраслей (одежда, обувь, отдельные категории товаров) кабинет дилера рано или поздно должен будет учитывать требования системы маркировки «Честный знак» и электронный документооборот с контрагентами — это стоит закладывать в архитектуру заранее, даже если на старте эти модули не подключаются.

Варианты реализации

Есть несколько принципиально разных путей построить такой кабинет, и выбор сильно влияет на сроки и стоимость.

1. Готовый модуль/коробочное решение поверх существующей CMS (например, модуль B2B для 1С-Битрикс или Сотбит). Быстрее всего запустить, но менее гибко под нестандартные бизнес-процессы.
2. Кастомная разработка кабинета с нуля с интеграцией по API. Максимальная гибкость под конкретные процессы компании (лимиты, дебиторка, сложные схемы резервов), но дольше и дороже.
3. Отдельная B2B-платформа (SaaS или коробка), синхронизируемая с 1С. Промежуточный вариант: готовая функциональность кабинета плюс настраиваемая интеграция.
4. Модуль в самой 1С, синхронизирующий базу с внешним порталом — вариант, при котором учётная система активнее участвует в логике обмена, а не просто отдаёт данные по запросу.

Важно определиться на старте: нужен ли закрытый кабинет только для существующих дилеров с индивидуальными условиями, или параллельно нужна открытая витрина для привлечения новых клиентов — если нужен открытый каталог для привлечения новых клиентов, это уже ближе к обычному сайту с другими этапами и сроками разработки [1]. Смешивать эти две задачи в одном модуле обычно неэффективно.

Практические этапы внедрения

1. Аудит текущего состояния. Фиксируется, какие регистры и подсистемы учётной системы задействованы, какие версии конфигураций используются и какие доработки уже есть [18] — это даёт понимание, где изменение интеграции может задеть критичные процессы продаж.
2. Наведение порядка в номенклатуре и складах в 1С. Ошибка, которую часто повторяют, — стартовать без минимальной уборки номенклатуры и складов, надеясь «потом поправить в портале» [5]. Кабинет не может показывать чистые данные, если в источнике беспорядок.
3. Выбор способа обмена (CommerceML / API / промежуточный сервис) исходя из требуемой скорости обновления цен и остатков и допустимой нагрузки на учётную систему.
4. Настройка ролей доступа и типов цен для каждой группы контрагентов, проверка, что индивидуальные соглашения корректно передаются в кабинет, а не только типовые.
5. Пилотный запуск на ограниченной группе дилеров. Попытка одномоментно «переключить» всех клиентов на новый канал редко проходит гладко — в оптовых продажах любая ошибка в заказе превращается в прямые потери [19], поэтому чаще практикуют гибридный переход: часть клиентов работает через кабинет, часть — по-старому, пока процесс не обкатан.
6. Настройка мониторинга обмена. Нужно отдельно контролировать, что интеграция «жива» — обрывы обмена без уведомления приводят к тому, что кабинет тихо показывает устаревшие данные.
7. Масштабирование на весь объём контрагентов и каталога после того, как пилот подтвердил стабильность.

Ограничения, ошибки и риски

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

Слабая защита канала обмена. Базовая аутентификация логином и паролем в открытом виде уязвима: при авторизации через basic auth пароль передаётся в открытом виде в base64-строке, которая легко декодируется [21]. Современный подход — токены с ограниченным сроком действия: токен можно представить как одноразовый ключ с ограниченным сроком действия и правами, который открывает только нужные двери и только на нужное время [22].

Рекомендуемый минимальный набор мер защиты для API-интеграции: создание отдельной учётной записи с ограниченными правами, разграничение операций по ролям (например «Пользователь API», «Чтение данных»), использование OAuth 2.0 для сложных интеграций, базовая аутентификация только через HTTPS и IP-фильтрация — разрешение доступа только с доверенных адресов контрагентов [23].

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

Игнорирование резервов при расчёте «доступного остатка». Если кабинет показывает валовый остаток на складе без вычета резервов других заказов, дилеры регулярно будут заказывать то, что уже занято.

Попытка охватить сразу весь ассортимент и всех клиентов. Частая ошибка — пытаться отразить все нюансы ассортимента сразу для всех клиентов, не начиная с пилотной группы и приоритетных сценариев [5].

Отказ от проекта «мы ещё слишком малы». Даже если оптовые заказы обрабатывают всего два менеджера, этого уже достаточно, чтобы задуматься о внедрении — при нормальной организации затраты на разработку окупаются в течение примерно полугода экономии на одной только зарплате менеджеров [3] (эта оценка приводится отраслевым игроком как ориентир, а не универсальное правило — фактическая окупаемость зависит от объёма заказов и стоимости разработки конкретного проекта).

Рекомендации по выбору решения

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

• Сложность ценообразования. Если условия сводятся к 2–3 типам цен на группы клиентов — обычно достаточно готового модуля поверх CMS. Если у каждого крупного дилера индивидуальный набор скидок, лимитов и условий оплаты — потребуется более глубокая кастомизация обмена с 1С.
• Требуемая скорость обновления остатков. Для товаров с высокой оборачиваемостью и небольшими партиями критична близкая к реальному времени синхронизация (API), для медленно оборачиваемых складских позиций может хватить периодического CommerceML-обмена.
• Готовность 1С-базы к интеграции. Если номенклатура и склады в текущей базе уже в порядке — можно запускать проект сразу; если нет, потребуется отдельный этап на наведение порядка, и это стоит закладывать в срок и бюджет.
• Объём и разнообразие интеграций помимо 1С. Если помимо учётной системы нужно подключать ЭДО, маркировку, CRM и логистику — это аргумент в пользу кастомной архитектуры, а не готового узкого модуля.

Конкретные сроки и стоимость такого проекта сильно зависят от состояния текущей 1С-базы, количества видов цен и глубины кастомизации кабинета, поэтому в статье они намеренно не приводятся — это предмет отдельной оценки под конкретный проект.

Как может помочь «Пятый фактор»

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

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

Как показывать цену и остаток, которым можно доверять

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

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

Вывод

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

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

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

Источники

[1] zaytsv.com — B2B-портал и личный кабинет дилера для оптовой компании — https://zaytsv.com/articles/b2bportal-i-lichnyy-kabinet-dilera-dlya-optovoy-kompanii-2026-06-30

[2] kaizenteam.xyz — Что такое B2B-портал: отличия от корпоративного сайта и роль личного кабинета — https://kaizenteam.xyz/blog/chto-takoe-b2b-portal-otlichiya-ot-korporativnogo-sajta-i-rol-lichnogo-kabineta-v-avtomatizaczii-optovyh-prodazh

[3] compob2b.ru — Типовые ошибки при разработке B2B порталов — https://compob2b.ru/common_fails_when_developing_b2b_portals

[4] olprime.ru — Интеграция 1С с сайтом: как устроен обмен данными и цены — https://olprime.ru/blog/integraciya-1s-s-saytom/

[5] order2b.ru — Как выстроить управление ассортиментом и остатками в B2B-продажах — https://order2b.ru/kak-organizovat-upravlenie-assortimentom-i-ostatkami-dlya-optovyh-klientov-chere.html

[6] assino.ru — Как в 1С:ERP настроить скидки и виды цен — https://assino.ru/news/kak-v-1s-erp-nastroit-skidki/

[7] koderline.ru — В чём разница между договором и соглашением с контрагентами в 1С — https://www.koderline.ru/expert/narabotki/article-dogovory-i-soglasheniya-s-kontragentami-v-sisteme-ucheta-1s-raznitsa-i-naznachenie/

[8] sotbit.ru — Персональные цены в B2B: зачем это нужно в онлайне — https://www.sotbit.ru/info/b2b/personalnye-tseny-v-b2b.html

[9] s-alpha.ru — Модуль B2B-SKIDKI: выгрузка скидок и договоров из 1С в Битрикс — http://vps.s-alpha.ru/article/moduli-dlya-portala-b2b/modul-b2b-skidki-vygruzka-skidok-i-dogovorov-iz-1s-v-bitriks/

[10] infostart.ru — Актуальные цены и остатки на сайте: как связать B2B-портал с 1С — https://infostart.ru/journal/news/mir-1s/aktualnye-tseny-i-ostatki-na-sayte-kak-svyazat-b2b-portal-s-1s_2704116/

[11] abcraftgroup.ru — Новый продукт — B2B-портал оптовых продаж на 1С (ABcraft, Владивосток) — https://vladivostok.abcraftgroup.ru/news/b2b-portal-optovyh-prodazh-na-1s/

[12] dev.1c-bitrix.ru — Количественный учёт и резервирование товара в интернет-магазине — https://dev.1c-bitrix.ru/community/blogs/product_features/quantitative-accounting-and-redundancy-of-goods.php

[13] march-code.ru — Интеграция 1С с сайтом: способы и стоимость — https://march-code.ru/blog/integraciya-1s-s-saitom

[14] v8.1c.ru — Протокол обмена с сайтом (CommerceML 2) — https://v8.1c.ru/tekhnologii/obmen-dannymi-i-integratsiya/standarty-i-formaty/protokol-obmena-s-saytom/

[15] amsales.ru — Интеграция сайта с 1С: настройка обмена без ошибок — https://amsales.ru/journal/integraciya-sayta-s-1s-nastroyka-obmena-bez-oshibok/

[16] e-krit.ru — Заказать настройку интеграции интернет-магазина с 1С — https://e-krit.ru/services/integration-1c/

[17] seohead.pro — Интеграция сайта с 1С: как правильно внедрить без ошибок — https://seohead.pro/blog/integratsiya-sayta-1s-nuzhno-pravilno-vnedrit/

[18] order2b.ru — Как масштабировать интеграцию 1С и B2B-портала заказов под большой каталог — https://order2b.ru/kak-masshtabirovat-integraciyu-1s-i-b2b-portala-zakazov-pod-bolshoi-katalog-i-ro.html

[19] order2b.ru — Как перевести оптовых клиентов на B2B-портал с 1С через гибридный режим — https://order2b.ru/kak-perevesti-optovyh-klientov-na-b2b-portal-zakazov-s-integraciei-1s-cherez-gib.html

[20] sellty.ru — ТОП-8 ошибок при запуске B2B-портала — https://sellty.ru/tpost/yvi712emz1-top-8-oshibok-pri-zapuske-b2b-portala-ka

[21] is1c.ru — JWT-авторизация — https://is1c.ru/about/pc/article/jwt-avtorizatsiya/

[22] binavigator.ru — Современная интеграция 1С: REST API, OData и асинхронность — https://binavigator.ru/articles/servisy-1s/sovremennaya-integratsiya-1s-rest-api-1s-shina-i-arkhitektura-besshovnykh-resheniy/

[23] saifield.ru — API «1С» для взаимодействия с контрагентами: настройка и безопасность — https://saifield.ru/api-1%D1%81-%D0%B4%D0%BB%D1%8F-%D0%B2%D0%B7%D0%B0%D0%B8%D0%BC%D0%BE%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8%D1%8F-%D1%81-%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%B0%D0%B3%D0%B5%D0%BD%D1%82/

[24] infostart.ru — Настройка аутентификации в 1С с использованием стандарта RFC 7519 (JWT) — https://infostart.ru/1c/articles/2049126/