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

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

Правильно заповнені характеристики — основа фасетного фільтру. Без них розумний фільтр bitrix:catalog.smart.filter не працює, а покупець не може відібрати товари за параметрами. Автоматизація заповнення характеристик складніша, ніж автоматизація описів: потрібно підтримувати схему властивостей інфоблоку, нормалізовувати різнорідні дані та стежити за консистентністю значень списочних властивостей.

Проєктування схеми властивостей під автоматизацію

Перед початком — аудит поточних властивостей інфоблоку. Типові проблеми успадкованих каталогів:

• Характеристики зберігаються в одній текстовій властивості «Опис» через переноси рядків
• Одна й та сама властивість створена кілька разів з різними CODE
• Числові значення зберігаються в рядкових властивостях, фільтр не працює коректно

Для автонаповнення потрібна чиста схема: кожна характеристика — окрема властивість з правильним типом. Числа — тип N, категорії (бренд, колір, матеріал) — тип L (список), текстові — тип S.

Джерела характеристик

Icecat XML — найповніше джерело для електроніки та побутової техніки. Пошук за EAN через https://icecat.us/api/. Дані структуровані, назви характеристик стандартизовані.

GS1 / GEPIR — база даних за штрихкодами, містить базові атрибути товару.

API виробника — якщо виробник надає партнерський доступ до специфікацій.

Парсинг сайту виробника — fallback при відсутності API. Таблиці специфікацій парсимо як описано в статті про парсинг характеристик.

Нормалізація та контроль якості

Головна проблема: один і той самий параметр з різних джерел може називатися по-різному та мати різні одиниці вимірювання.

Архітектура нормалізації:

1. Словник канонічних імен — таблиця property_canonical_map:

   source: 'icecat', source_name: 'Screen Size', canonical: 'display_diagonal', unit: 'inch'
   source: 'supplier_a', source_name: 'Діагональ екрана', canonical: 'display_diagonal', unit: 'sm'
   

2. Конвертер одиниць — при імпорті автоматично конвертує см у дюйми (або навпаки) за canonical
3. Валідатор діапазонів — числові значення перевіряються на реалістичність (вага телефону 5000 г — явна помилка)

Управління enum-значеннями списочних властивостей

Властивості типу L вимагають попереднього створення значень у b_iblock_prop_enum. При автонаповненні нові значення з'являються постійно — потрібна стратегія:

Автостворення — нове значення автоматично додається в enum. Ризик: сміттєві значення від помилок парсингу (друкарські помилки, HTML-теги у значенні).

Черга на модерацію — нове значення потрапляє в чергу, менеджер підтверджує або відхиляє. Безпечніше, але вимагає уваги.

Рекомендую комбінацію: автостворення з фільтрацією (довжина > 2 і < 100 символів, без HTML, без спецсимволів) + сповіщення менеджеру про нові значення.

Інкрементальне оновлення

Характеристики змінюються рідше, ніж ціни — раз на тиждень достатньо для більшості каталогів. Оптимізація:

• Зберігаємо хеш набору характеристик елемента: md5(serialize($properties))
• При оновленні з джерела порівнюємо хеш — якщо не змінився, пропускаємо запис у БД
• Це знижує навантаження на b_iblock_element_property при великих обсягах

Таймлайн робіт

Разом: 7–12 робочих днів — одне з найтрудомісткіших завдань автонаповнення через необхідність роботи зі схемою даних.