Мобильное приложение B2B-портала на Битрикс

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

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

Зачем оптовику мобильное приложение

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

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

• Сохранённая авторизация. В браузере сессия слетает, пароль забывается, вход через десктопную форму на телефоне неудобен. Приложение помнит пользователя и открывается сразу в его личный ассортимент.
• Иконка на домашнем экране. Это постоянное напоминание о поставщике. Психологически повторный заказ начинается с одного касания, а не с набора адреса в браузере.
• Скорость. Локальный кэш каталога и состояние корзины на устройстве дают отклик, которого мобильный сайт на слабой связи не обеспечит.
• Push-канал. Уведомления о статусах, новых ценах и акциях приходят напрямую, а не теряются в почте. Это единственный способ дотянуться до закупщика в нужный момент.
• Работа в полях. На складе и в разъездах связь нестабильна. Приложение с офлайн-режимом позволяет собрать корзину без сети и отправить заказ, как только появится интернет.

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

Сценарии закупщика: где приложение выигрывает у сайта

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

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

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

Менеджер клиента в разъездах. Оформляет заказы за нескольких клиентов, проверяет статусы отгрузок, отвечает на вопрос «когда приедет». Ключевой экран — список заказов со статусами и уведомления.

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

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

Быстрый повторный заказ в пару касаний

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

• История заказов. Список прошлых заказов с кнопкой «Повторить»: одним касанием весь состав прошлой закупки уезжает в корзину, а недоступные позиции подсвечиваются.
• Шаблоны закупок. Сохранённые наборы «еженедельный заказ», «сезонный ассортимент» с возможностью поправить количества перед отправкой.
• Избранное и «часто заказываю». Персональная подборка на основе истории — самый быстрый путь для регулярных позиций.
• Добавление по артикулу. Ввод или сканирование артикула — и позиция сразу в корзине с нужным количеством. Незаменимо, когда закупщик работает со списком на бумаге или в Excel.
• Загрузка списка. Возможность вставить список артикулов и количеств и получить готовую корзину. Логику массового ввода мы подробно разбирали в статье про быстрый заказ по артикулу и загрузку из Excel — в приложении та же механика адаптируется под касания и сканер.

Механика «Повторить заказ» на бэкенде проста: приложение запрашивает состав прошлого заказа, а сервер на стороне Битрикса пересобирает корзину с актуальными ценами и остатками. Здесь важен один нюанс, о котором часто забывают: цены и наличие с момента прошлой закупки могли измениться. Приложение обязано пересчитать корзину по текущему прайсу контрагента и честно показать, что позиции A нет в наличии, а позиция B подорожала. Иначе закупщик оформит заказ на старых условиях и получит расхождение при отгрузке.

Каталог с персональными ценами и остатками

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

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

Что должно быть в мобильном каталоге для опта, помимо цены:

• Остаток и наличие. Не «есть/нет», а понятная градация: в наличии, мало, под заказ, с датой поступления. Оптовику критично планировать закупку от реального остатка.
• Единицы и кратность. Продажа коробками, паллетами, упаковками. Приложение должно уважать кратность отгрузки и не давать заказать «полкоробки».
• Персональный ассортимент. Дилер видит только доступные ему товары и бренды. О том, как формируется индивидуальная витрина, мы писали в материале про персональный ассортимент B2B на Битрикс — приложение показывает ровно тот же срез каталога, что и портал.
• Поиск по артикулу и коду. Основной способ навигации снабженца — не по разделам, а по точному коду позиции.
• Быстрое количество. Крупные кнопки «+/−» и поле ввода количества, рассчитанные на касание пальцем, а не мышью.

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

Статусы заказов и push-уведомления

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

Цепочка статусов. В приложении заказ показан не как строчка «в работе», а как понятная лента этапов с датами: принят → подтверждён → собирается → отгружен → доставлен → закрыт. Каждый этап соответствует статусу заказа в 1С-Битрикс, а даты подтягиваются из истории смены статусов. Закупщик в любой момент видит, на каком шаге его закупка и когда ждать поставку.

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

Обратите внимание на колонку push: обязательные уведомления касаются заказа самого пользователя, а маркетинговые (цены, поступления) — только по явной подписке. Это разделение защищает канал от превращения в спам и сохраняет доверие к уведомлениям.

Архитектура: приложение поверх B2B-портала

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

Такая архитектура даёт несколько важных преимуществ:

• Единый источник правды. Цена и остаток считаются в одном месте. Не нужно синхронизировать две системы и ловить расхождения.
• Переиспользование логики. Скидки, персональный ассортимент, права доступа контрагента уже реализованы на портале и работают для приложения без переписывания.
• Простое сопровождение. Изменили условия в 1С — они автоматически доехали и до сайта, и до приложения через один и тот же обмен.
• Быстрый старт. Не нужно строить бэкенд с нуля: достаточно надстроить REST-слой над готовым порталом.

Между приложением и порталом стоит API-слой — набор REST-эндпоинтов, которые отдают данные в формате, удобном мобильному клиенту. Ниже — как связаны компоненты в такой архитектуре.

Нативное, PWA или гибрид: что выбрать

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

PWA (прогрессивное веб-приложение). По сути, это мобильный сайт портала, который умеет ставиться на домашний экран, работать офлайн через сервис-воркер и присылать push. Плюсы: переиспользует вёрстку портала, одна кодовая база, обновляется без ревью в сторах, быстрый и дешёвый старт. Минусы: ограниченный доступ к системным функциям, push на iOS появились относительно недавно и с оговорками, нет присутствия в App Store и Google Play.

Нативное приложение. Отдельные приложения под iOS и Android на «родных» технологиях. Плюсы: максимальная скорость и плавность, полноценные фоновые push, надёжный офлайн, доступ к камере и сканеру штрихкодов, место в сторах как канал доверия. Минусы: две кодовые базы (или кросс-платформенный фреймворк), дороже в разработке и поддержке, релизы проходят через ревью магазинов.

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

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

REST API 1С-Битрикс как бэкенд приложения

Технической основой связки «приложение — портал» служит REST API. 1С-Битрикс предоставляет механизм REST через модуль веб-сервисов и приложения (в том числе локальные), а также позволяет писать собственные эндпоинты в составе решения. Для мобильного клиента обычно проектируют выделенный набор методов, заточенных под экраны приложения, чтобы не тянуть на телефон лишние данные.

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

• Авторизация. Обмен логина/пароля или одноразового кода на токен доступа и токен обновления. Токен несёт привязку к пользователю и контрагенту.
• Каталог и разделы. Постраничная выдача товаров с персональными ценами и остатками, поиск по названию и артикулу, фильтр.
• Корзина. Добавить/изменить/удалить позицию, пересчитать по актуальному прайсу, применить условия контрагента.
• Заказы. Оформить заказ, получить список заказов, детали и историю статусов, повторить заказ.
• Документы. Список закрывающих документов заказа и ссылки на скачивание.
• Устройства и push. Регистрация токена устройства и управление подписками на уведомления.

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

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

Авторизация и привязка к контрагенту

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

Как обычно устроена авторизация в мобильном B2B-приложении:

1. Первый вход. Пользователь вводит логин и пароль от личного кабинета портала или получает одноразовый код на телефон/почту. Приложение обменивает их на пару токенов.
2. Привязка к профилю. Токен несёт идентификатор пользователя, а сервер по нему определяет контрагента, договор и ценовую категорию. Все дальнейшие запросы уже персональны.
3. Хранение сессии. Токены хранятся в защищённом хранилище устройства, вход не нужно повторять при каждом открытии. Для чувствительных действий можно требовать биометрию.
4. Обновление токена. Короткоживущий токен доступа периодически обновляется по токену обновления без повторного ввода пароля.
5. Выход и отзыв. При выходе или потере устройства токен отзывается на сервере, и доступ к персональным ценам закрывается.

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

Офлайн-режим и синхронизация корзины

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

Разумный объём офлайн-функций для оптового приложения:

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

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

Как устроены push изнутри

Push-уведомления кажутся простой функцией, но за ними стоит цепочка из нескольких звеньев, и понимание этой цепочки помогает избежать типичных проблем «уведомления не приходят». Разберём путь push от события в 1С-Битрикс до экрана телефона.

1. Регистрация устройства. При установке и входе приложение получает от системного сервиса (для Android и iOS это платформенные сервисы доставки) токен устройства и отправляет его на сервер Битрикса, привязывая к профилю пользователя.
2. Событие на портале. В 1С-Битрикс срабатывает обработчик события — например, смена статуса заказа. Обработчик определяет, кому и о чём нужно сообщить.
3. Постановка в очередь. Сервер формирует уведомление и ставит его в очередь отправки, чтобы не блокировать основной процесс и справляться с массовыми рассылками.
4. Отправка через сервис доставки. Уведомление уходит в платформенный сервис push, который доставляет его на устройства по сохранённым токенам.
5. Показ и переход. Приложение показывает уведомление и по касанию открывает нужный экран — конкретный заказ, обновлённый прайс, готовый документ.

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

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

Реализация в 1С-Битрикс пошагово

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

1. Подготовьте REST-слой. Подключите модуль веб-сервисов, спроектируйте набор эндпоинтов под экраны приложения (каталог, корзина, заказы, статусы, документы, push) и настройте выдачу персональных цен по токену контрагента.
2. Настройте авторизацию и токены. Реализуйте вход по паролю или одноразовому коду, выдачу пары токенов доступа и обновления, привязку токена к пользователю, контрагенту и ценовой категории.
3. Обеспечьте персональные цены и ассортимент. Убедитесь, что REST отдаёт цены по ценовой категории клиента и урезанный до его прав каталог — та же логика, что на портале, без дублирования правил.
4. Реализуйте повторный заказ. Добавьте методы «получить состав заказа» и «пересобрать корзину по актуальному прайсу», а также сохранение шаблонов закупок.
5. Свяжите статусы с событиями. На смену статуса заказа в Битриксе повесьте обработчик, который ставит задачу на push и обновляет ленту статусов в приложении.
6. Подключите сервис push. Настройте регистрацию токенов устройств, очередь отправки и интеграцию с платформенными сервисами доставки уведомлений.
7. Соберите клиент. Разработайте PWA/гибрид/нативное приложение с ключевыми экранами, кэшированием каталога и офлайн-корзиной.
8. Настройте кэш и нагрузку. Закэшируйте тяжёлые выборки каталога на сервере, включите пагинацию, проверьте отклик REST под нагрузкой.
9. Протестируйте на устройствах. Проверьте цены под разными контрагентами, повтор заказа, статусы, push и офлайн на реальных iOS и Android.
10. Опубликуйте. Для PWA — настройте установку с портала; для гибрида/натива — подготовьте и проведите публикацию в App Store и Google Play.

Как это выглядит в админке и в приложении

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

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

Безопасность и разграничение доступа

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

Базовый контур защиты:

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

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

Метрики и эффект для опта

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

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

Частые ошибки при запуске приложения

• Строят приложение как «второй сайт» со своей базой и логикой — получают рассинхрон цен и двойную поддержку вместо надстройки над порталом.
• Переносят в мобильный формат весь портал целиком — первая версия перегружена, а ключевой сценарий повторного заказа теряется среди десятков экранов.
• Не пересчитывают корзину по актуальному прайсу при повторе заказа — клиент оформляет закупку по старым ценам и получает конфликт при отгрузке.
• Отдают цены анонимно или кэшируют общий прайс — риск показать чужие условия и утечка договорных цен.
• Грузят весь каталог одним запросом — приложение тормозит на мобильной связи и «съедает» трафик.
• Меняют статусы заказов в обход событий ядра — обработчики не срабатывают, push не уходят, лента статусов расходится с реальностью.
• Заваливают пользователя маркетинговыми push без подписки — закупщик отключает уведомления в системе, и канал теряется целиком.
• Игнорируют офлайн и слабую связь — приложение бесполезно ровно там, где закупщик работает: на складе и в разъездах.
• Не чистят кэш чувствительных данных при выходе — новый пользователь на устройстве видит остатки чужих цен и документов.

Чек-лист внедрения

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

1. Сценарии определены. Выделены три-четыре ключевые операции закупщика: повторный заказ, персональная цена и остаток, контроль статусов.
2. Технология выбрана осознанно. Решено, стартуем с PWA, гибрида или натива, исходя из потребности в офлайне, сканере и сторах, а не «на всякий случай».
3. REST-слой готов. Спроектированы компактные, версионированные, кэшируемые эндпоинты под экраны приложения.
4. Авторизация связана с контрагентом. Токен несёт профиль, договор и ценовую категорию; поддержано переключение юрлиц.
5. Персональные цены и ассортимент. Приложение показывает прайс по договору и урезанный до прав каталог, тем же правилам, что и портал.
6. Повторный заказ работает. Есть история, шаблоны, добавление по артикулу и честный пересчёт корзины по актуальным ценам и остаткам.
7. Статусы и push настроены. Смена статуса триггерит событие и уведомление; транзакционные и маркетинговые push разделены.
8. Офлайн продуман. Кэш каталога, локальная корзина, отложенная отправка и честный пересчёт при выходе в сеть.
9. Безопасность закрыта. HTTPS, короткие токены, проверка прав на сервере, изоляция контрагентов, очистка кэша при выходе.
10. Метрики заведены. Считаются доля заказов из приложения, частота повторов, время оформления и открываемость push.

Вывод

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