Настройка модерации товаров продавцов на маркетплейсе 1С-Битрикс

Представьте: продавцы выгружают до 10 000 товаров в день на маркетплейсе на 1С-Битрикс. Без системы модерации — дубли (до 30%), товары без фото, цены «0 рублей», запрещённые категории. Стандартный модуль Интернет-магазина не предоставляет гибких статусов — только активность товара (Y/N). Для полноценного маркетплейса нужно расширение с кастомными UF-полями, событиями и автоматическими проверками. Мы автоматизируем процесс так, чтобы 80% проверок выполнялись без участия человека, а продавец видел статус в личном кабинете и получал уведомления о причинах отказа. Наш опыт — более 7 лет разработки на 1С-Битрикс, 50+ проектов, сертифицированные специалисты. Рассмотрим детально: какие статусы использовать, как настроить обработчики событий, какие проверки внедрить для снижения нагрузки на модераторов.

Статусная модель модерации

Каждый товар в инфоблоке получает UF-поле статуса модерации: UF_MODERATION_STATUS (тип — строка или справочник). Значения:

• draft — продавец не отправил на проверку
• pending — ожидает проверки модератором
• approved — одобрено, товар активен (ACTIVE = Y)
• rejected — отклонено с указанием причины
• revision — нужны правки (мягкий отказ)

При добавлении товара продавцом устанавливается ACTIVE = N, UF_MODERATION_STATUS = 'pending'. Обработчик события OnAfterIBlockElementAdd фиксирует время отправки и создаёт уведомление для модераторов. Если требуется асинхронная обработка, используем агента с CAgent::AddAgent().

Пример обработчика:

AddEventHandler("iblock", "OnAfterIBlockElementAdd", function(&$arFields) {
    if ($arFields["IBLOCK_ID"] == CATALOG_IBLOCK_ID) {
        CIBlockElement::SetPropertyValuesEx($arFields["ID"], CATALOG_IBLOCK_ID, array(
            "UF_MODERATION_STATUS" => "pending"
        ));
        // уведомление модераторам
        CEvent::Send("MODERATION_NEW_ITEM", SITE_ID, array(
            "ITEM_ID" => $arFields["ID"],
            "NAME" => $arFields["NAME"]
        ));
    }
});

Почему автоматические проверки критичны?

Ручная модерация каждого товара — бутылочное горлышко. Мы внедряем автоматические проверки, которые работают в 3 раза быстрее и допускают менее 1% ошибок (против 5-10% вручную). Продавец получает мгновенный ответ и может исправить ошибки без ожидания модератора.

Дополнительно можно проверять соответствие требованиям категории (например, обязательное свойство "Бренд" для электроники). Автоматическая проверка сокращает время модерации до 0.1 секунды на товар.

Какие проверки стоит автоматизировать?

Кроме базовых проверок, описанных выше, стоит автоматизировать:

• Валидацию цены: не меньше минимального порога и не больше максимального.
• Проверку уникальности названия в рамках категории.
• Фильтрацию нецензурных слов в описании.
• Соответствие изображений формату и размеру (например, JPEG, не более 2 МБ).

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

Как настроить уведомления продавцов?

Используем событийную модель Битрикс: CEvent::Send() с шаблонами почтовых событий. При одобрении — письмо с активной ссылкой на товар. При отказе — причина и список ошибок. Можно добавить уведомления через SMS или мессенджеры через REST API. Также настраиваем уведомления в личном кабинете продавца: статус товара обновляется в реальном времени через BX.Pull.

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

Пошаговая настройка модерации

1. Создать UF-поле UF_MODERATION_STATUS для инфоблока каталога.
2. Написать обработчик OnAfterIBlockElementAdd для установки статуса pending и ACTIVE=N.
3. Разработать автоматические проверки в виде агента или обработчика OnBeforeIBlockElementUpdate.
4. Настроить почтовые события и шаблоны для уведомлений.
5. Реализовать интерфейс модератора: очередь товаров с фильтрацией по статусу, кнопки "Одобрить", "Отклонить", "Запросить правки".

Что входит в настройку под ключ?

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

• Проектирование статусной модели под ваш каталог с учётом номенклатуры и категорий
• Разработка интерфейса модератора (очередь, карточка товара, история решений)
• Система уведомлений продавцов (почта, личный кабинет, опционально SMS через REST API)
• Автоматические проверки (изображения, обязательные поля, дубли, безопасность)
• Интеграция с REST API для обмена данными с внешними системами
• Документация по настройке и инструкции для модераторов
• Обучение команды (2 часа онлайн)
• Поддержка 2 недели после запуска

Результаты внедрения: снижение нагрузки на модераторов на 70%, ускорение публикации товаров в 5 раз. Мы даём гарантию на стабильную работу: все статусы корректно обновляются, уведомления доставляются, дубли блокируются. Опыт 7+ лет и 50+ проектов позволяют предвидеть типовые проблемы. Официальная документация Битрикс по событиям подтверждает надёжность такого подхода.

Для оценки вашего проекта свяжитесь с нами — получите консультацию инженера. Мы рассчитаем стоимость и сроки индивидуально.

Разработка маркетплейсов на 1С-Битрикс: как преодолеть ограничения стандартной архитектуры

Таблица b_sale_order и связанные с ней b_sale_basket не рассчитаны на мультивендорность из коробки. В Битриксе нет штатного модуля «маркетплейс» — каждый раз это кастомная разработка поверх модуля sale. Стандартный модуль sale не умеет разделять заказ по разным поставщикам: если в корзине товары от трёх продавцов, Битрикс создаст один заказ с единым номером, статусом и общей суммой. Невозможно отправить каждый субзаказ в отдельный личный кабинет, рассчитать комиссию для каждого продавца или разрешить им частичную отгрузку. Нам приходится переопределять всю логику: от корзины до статусной модели. Дополнительно стандартный поиск (Sphinx) и кэширование не оптимизированы под мультивендорный каталог — при 100 000 товаров от 500 поставщиков фильтры по поставщику приводят к падению производительности (запросы с WHERE по IBLOCK_ELEMENT_PROPERTY становятся медленнее в 5–10 раз). Мы пишем отдельный модуль, который расширяет стандартную корзину: добавляет привязку товара к поставщику через свойство заказа, разбивает один заказ на субзаказы по продавцам и маршрутизирует каждый отдельно.

Почему стандартные решения не подходят для мультивендорных площадок?

Модели маркетплейсов

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

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

Маркетплейс услуг — заявки, тендеры, эскроу. Тут вместо b_sale_basket работает кастомная сущность заявки с воркфлоу через бизнес-процессы Битрикс.

B2B-маркетплейс — договоры, акты сверки, кредитные линии, EDI. Авторизация по ИНН, мультиценовые группы через b_catalog_group, лимиты отгрузки.

Какие технические проблемы решает разработка маркетплейсов на 1С-Битрикс?

Модели монетизации

Что включает кабинет продавца?

Кабинет — сердце маркетплейса. Неудобный кабинет = пустая площадка. Стандартного решения нет, пишем с нуля на компонентах Битрикс.

• Управление каталогом — CRUD товаров через кастомный компонент, массовая загрузка CSV/XML через CIBlockXMLFile. Вручную вбивать 10 000 SKU никто не станет, поэтому импорт — первое, что делаем.
• Обработка заказов — субзаказы падают в кабинет через ajax-polling или websocket. Подтверждение, печать накладных через CSalePdf, обновление статуса с обратной синхронизацией в основной заказ.
• Финансовая аналитика — дашборд на highload-инфоблоке агрегированных данных. Выручка, комиссии, выплаты — детализация по товарам и периодам. Продавец видит, что продаётся, а что просто занимает витрину.
• Настройки доставки — собственные тарифы продавца, привязка к sale.delivery.handler.
• Коммуникация — встроенный чат без раскрытия контактов. Реализуем через модуль im или кастомную таблицу сообщений.
• Акции — скидки, промокоды через b_sale_discount с фильтром по vendor_id.

Модерация и контроль качества

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

• Модерация товаров — статус ACTIVE='N' до прохождения проверки. Автомодерация отсекает очевидное (запрещённые слова, отсутствие фото), ручная разбирает спорное. Обработчик OnBeforeIBlockElementUpdate не даёт обойти.
• Верификация продавцов — проверка ИНН через API ФНС, загрузка сканов документов. Статусы: новый → проверенный → премиум. Каждый уровень открывает лимиты по количеству товаров и комиссиям.
• Рейтинговая система — не просто звёзды. Алгоритм учитывает скорость отправки (AVG(ship_date - order_date)), процент возвратов, качество ответов на вопросы.
• Антифрод — детектим накрутку рейтингов по паттернам (один IP, одинаковые тексты, аномальная частота). Дублирование аккаунтов ловим по ИНН и банковским реквизитам.
• Типичная ошибка: хранение данных о поставщиках в обычном инфоблоке — при 1000+ продавцов запросы становятся тормозными. Используйте highload-инфоблоки.

Как устроена система выплат продавцам?

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

• Расчёт комиссии — обработчик на смену статуса заказа. Комиссия зависит от категории, статуса продавца, текущих условий. Хранится в отдельной таблице vendor_transactions.
• Периодические выплаты — cron-задача формирует реестр: еженедельно, дважды в месяц или ежемесячно. Минимальная сумма выплаты, холдирование до подтверждения получения.
• Акты и отчётность — генерация PDF актов через PhpOffice\PhpSpreadsheet, автоматическая нумерация, скачивание в один клик.
• Холдирование — деньги удерживаются до получения товара. Снижает споры и возвраты.
• Выплаты через банковские API — ЮKassa, CloudPayments, прямые банковские API. Продавец получает деньги без звонков и напоминаний.
• Важно: разделение заказов на уровне обработчика OnSaleOrderSaved приводит к расхождению статусов. Разделяйте на этапе корзины.
• Ручная фискализация каждого субзаказа нарушает 54‑ФЗ. Используйте единый чек с признаком «агент». На одном из проектов автоматизация фискализации сократила издержки на 400 000 руб. ежемесячно. На другом проекте оптимизация поиска через Elasticsearch сократила время загрузки каталога на 80% (с 3 секунд до 0.6 секунды).

Как мы строим архитектуру маркетплейса

1. Определение бизнес-модели — выбираем тип маркетплейса и схему монетизации.
2. Проектирование БД — highload-инфоблоки для каталогов свыше 50 000 SKU, отдельные таблицы для субзаказов (orders_split) и транзакций.
3. Разработка ядра — создаём модуль marketplace.vendor, реализуем привязку товаров к поставщикам, механизм разделения заказов, агенты для расчёта комиссий.
4. Интеграция платёжного шлюза и 54-ФЗ — настраиваем фискализацию через АТОЛ Онлайн или CloudPayments.
5. Тестирование на нагрузку — используем k6 или ab для проверки 5000 заказов в сутки.

Типичные ошибки при разработке маркетплейсов на Битрикс

• Хранение поставщиков в обычном инфоблоке — приводит к тормозам при >1000 записей. Используйте highload-инфоблоки.
• Разделение заказов после сохранения — нарушает статусную модель. Разделяйте на этапе корзины.
• Ручная фискализация каждого субзаказа — нарушает 54-ФЗ. Фискализируйте единым чеком с признаком агента.
• Игнорирование кэширования тегированного для каталога — при мультивендорности кэш сбрасывается целиком. Настраивайте теги по vendor_id.

Технологический стек

• 1С-Битрикс «Бизнес» или «Энтерпрайз» — модуль sale + catalog как фундамент. Мультивендорная обвязка — кастомные модули.
• Highload-инфоблоки — каталоги свыше 100 000 SKU. Обычные инфоблоки при таких объёмах падают на фильтрации: CIBlockElement::GetList с десятком свойств генерирует JOIN-ы на десятки таблиц b_iblock_element_prop_sNN. Highload решает это плоской структурой.
• Elasticsearch — полнотекстовый поиск. Elasticsearch обрабатывает запросы в 10 раз быстрее штатного модуля поиска (Sphinx). Пользователь пишет «кроссовки найки» — находит «Nike кроссовки».
• Очереди — импорт каталогов, расчёт выплат, генерация отчётов. Агенты Битрикс (CAgent) для лёгких задач, отдельная очередь через RabbitMQ или supervisor + кастомный CLI для тяжёлых.

Мы гарантируем, что разработанный модуль выдержит нагрузку до 5000 заказов в сутки на стандартном VPS. Сертифицированные специалисты 1С-Битрикс (опыт более 10 лет, 50+ реализованных проектов) выполняют аудит архитектуры до старта разработки. При масштабе 2000 продавцов среднее время модерации — 15 минут, а 95% заказов обрабатываются автоматически.

Отраслевые маркетплейсы

Каждая ниша — свои грабли:

• Стройматериалы — расчёт доставки крупногабарита. Паллеты, тоннаж, подъём на этаж. Обычный калькулятор доставки не справляется, пишем кастомный sale.delivery.handler.
• Продукты питания — сроки годности в свойствах инфоблока, температурный режим, слоты доставки «день в день». Ошибка в логистике = списание.
• Автозапчасти — подбор по VIN через laximo API, кросс-номера, оригиналы и аналоги. Отдельная headache — разные сроки поставки у разных продавцов на одну деталь.
• Одежда — размерные сетки (EU/US/RU), высокий процент возвратов. Логика обработки возвратов с перераспределением комиссии — отдельный пласт.
• Промоборудование — B2B с тендерами, запросами КП. Карточка товара с 50+ параметрами в табличном виде.

Сроки и этапы

Пытаться запустить всё сразу — надёжный способ не запустить ничего.

MVP за 3-4 месяца. Полнофункциональная платформа — 6-12 месяцев итеративной разработки.

Что входит в работу

• Документация: архитектурная схема, описание API, инструкции для продавцов.
• Доступы: репозиторий с кодом, тестовый стенд, админка.
• Обучение: две сессии для администраторов и менеджеров.
• Поддержка: 1 месяц бесплатного сопровождения после запуска, далее по SLA.
• Гарантия на разработанные модули — 12 месяцев.

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