Автонаповнення описів товарів у 1С-Бітрікс із зовнішніх джерел

Ви запустили інтернет-магазин на 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

Опис шукається послідовно: якщо перше джерело не дало результату — пробуємо наступне:

1. API виробника за VENDOR_CODE
2. База Icecat за EAN/штрихкодом
3. Парсинг сайту виробника
4. AI-генерація за назвою та характеристиками (крайній варіант)

Кожне джерело реалізує єдиний інтерфейс:

interface DescriptionProviderInterface { public function getDescription(string $sku): ?string; } 

Оркестратор перебирає провайдери в порядку пріоритету. Додатково кешуємо відповіді — якщо провайдер падає, використовуємо останній успішний результат.

Чому черга та пріоритетизація важливі?

Не всі товари однаково важливі. Пріоритет у черзі:

• Високий: товари з активними замовленнями або переглядами (дані з b_sale_order_item, b_stat_session)
• Середній: нові товари без опису
• Низький: старі товари, що не переглядались більше 30 днів

Реалізується через поле priority в таблиці черги, воркер вибирає завдання ORDER BY priority DESC. Це гарантує, що найважливіші позиції отримують опис в першу чергу.

Процес роботи

Типові помилки при автонаповненні:

• Затирання ручних правок: наше рішення з прапорцем DESCRIPTION_LOCKED виключає цю проблему.
• Нестабільні джерела: fallback та кешування відповідей забезпечують відмовостійкість.
• Змішування джерел: пріоритет та збереження мета-інформації дозволяють відстежити походження опису.

Що входить в результат

• Повністю реалізована система автонаповнення з чергою та пріоритетами
• Підключені джерела (до 4 в базовій версії)
• Механізм захисту ручних правок
• Документація з архітектури та експлуатації
• Навчання менеджерів (1 година)
• Технічна підтримка протягом 1 місяця після запуску