Вы запустили интернет-магазин на 1С-Битрикс. Тысячи товаров, но описания пустые или скопированы из прайса. Контент-менеджеры тратят часы на поиск и форматирование — и всё равно описания различаются стилем и качеством. Ошибки при копировании, дубли, неактуальная информация.
Выход — автоматизированное наполнение из внешних источников. Недавно к нам обратился клиент с каталогом 10 000 товаров электроники. Описания были только у 20%, остальные пустые. После внедрения системы заполнение достигло 95% за две недели. Наш fallback-подход обеспечивает стабильность в 3 раза выше, чем парсинг единичного источника.
Мы проектируем систему, которая сама собирает описания, не затирая ручные правки, и использует цепочку источников с fallback. Интеграция с любыми поставщиками через единый интерфейс провайдера. Получите консультацию по вашему проекту — оценим объём работ бесплатно.
Триггеры для заполнения описаний
Автонаполнение запускается в трёх ситуациях:
- При добавлении нового товара — обработчик события
OnAfterIBlockElementAdd. Товар только создан, поля пустые — система идёт за описанием в источники. - По расписанию для незаполненных — cron-задача находит элементы с пустым
DETAIL_TEXTи ставит их в очередь. - При ручном запросе — менеджер в административной части нажимает «Получить описание» для конкретного товара.
Как защитить ручные правки? Обработчик и флаг блокировки
Ключевой элемент — свойство DESCRIPTION_LOCKED (тип S, значения Y/N). Когда менеджер редактирует описание в административной части вручную:
- Устанавливается
DESCRIPTION_LOCKED = Y - Система автонаполнения пропускает этот элемент
Устанавливаем флаг через обработчик OnBeforeIBlockElementUpdate — проверяем, изменился ли DETAIL_TEXT относительно предыдущего значения. Если да и изменение пришло не от системы автонаполнения — ставим флаг.
В документации Bitrix Framework описан рекомендованный подход к контролю изменений через события.
Цепочка источников с fallback
Описание ищется последовательно: если первый источник не дал результата — пробуем следующий:
- API производителя по VENDOR_CODE
- База Icecat по EAN/штрихкоду
- Парсинг сайта производителя
- AI-генерация по названию и характеристикам (крайний вариант)
Каждый источник реализует единый интерфейс:
interface DescriptionProviderInterface {
public function getDescription(string $sku): ?string;
}
Оркестратор перебирает провайдеры в порядке приоритета. Дополнительно кэшируем ответы — если провайдер падает, используем последний успешный результат.
Почему очередь и приоритизация важны?
Не все товары одинаково важны. Приоритет в очереди:
- Высокий: товары с активными заказами или просмотрами (данные из
b_sale_order_item,b_stat_session) - Средний: новые товары без описания
- Низкий: старые товары, не просматривавшиеся более 30 дней
Реализуется через поле priority в таблице очереди, воркер выбирает задачи ORDER BY priority DESC. Это гарантирует, что самые важные позиции получают описание в первую очередь.
Процесс работы
| Этап | Описание |
|---|---|
| Архитектура провайдеров | Проектируем интерфейсы, описываем контракты для всех источников |
| Разработка провайдеров | Пишем провайдеры для API, Icecat, парсинга, AI (1–2 дня каждый) |
| Триггеры и очередь | Настраиваем обработчики событий и cron-воркер с приоритизацией |
| Защита ручных правок | Внедряем флаг блокировки и обработчик контроля изменений |
| Административный интерфейс | Добавляем кнопку ручного запроса, отображение статусов |
Типичные ошибки при автонаполнении:
- Затирание ручных правок: наше решение с флагом DESCRIPTION_LOCKED исключает эту проблему.
- Нестабильные источники: fallback и кэширование ответов обеспечивают отказоустойчивость.
- Смешение источников: приоритет и сохранение мета-информации позволяют отследить происхождение описания.
Что входит в результат
- Полностью реализованная система автонаполнения с очередью и приоритетами
- Подключённые источники (до 4 в базовой версии)
- Механизм защиты ручных правок
- Документация по архитектуре и эксплуатации
- Обучение менеджеров (1 час)
- Техническая поддержка в течение 1 месяца после запуска
Таймлайн работ
| Этап | Срок |
|---|---|
| Архитектура провайдеров, интерфейсы | 4–8 часов |
| Разработка провайдеров (1–2 дня каждый) | 2–6 дней |
| Триггеры, очередь, приоритизация | 1–2 дня |
| Защита ручных правок | 4–6 часов |
| Административный интерфейс | 1 день |
Итого: 6–12 рабочих дней в зависимости от числа источников.
Экономический эффект
Для каталога на 10 000 товаров ежегодная экономия составляет сотни тысяч рублей. Замена ручного труда автоматизацией позволяет сократить расходы в несколько раз. Проект окупается за 2–3 месяца.
Гарантируем, что после внедрения менеджеры тратят на описание товаров до 80% меньше времени. Сертифицированные специалисты с опытом более 10 лет. Свяжитесь с нами, чтобы обсудить ваш каталог и получить оценку.