При парсингу даних для каталогу 1С-Бітрікс часта ситуація: товари завантажуються, але фільтри не працюють, ціни відображаються з валютою, а категорії розкидані по дереву. Без шару трансформації між парсером та імпортером дані потрапляють «як є» — і ламають структуру каталогу. Наприклад, рядок із ціною потрапляє в поле ціни, і сортування за ціною перестає працювати. Ми налаштовуємо трансформацію під ключ і гарантуємо, що після імпорту каталог залишається чистим та консистентним. Оцінимо ваш проект за 1 день — просто зв'яжіться.
Офіційна документація 1С-Бітрікс підкреслює важливість попередньої валідації даних при імпорті.
Які трансформації потрібні при парсингу?
Нормалізація тексту — стандартне очищення від зайвих символів та приведення до єдиного регістру. Наприклад, ШУРУПОВЕРТ BOSCH GSR 18V стане Шуруповерт Bosch GSR 18V. Використовуємо mb_convert_case() з whitelist-ом для артикулів та брендів. Також видаляємо HTML-сутності (& → &) та нерозривні пробіли. Помилки в назвах — причина до 30% відбракування товарів при ручній перевірці.
Нормалізація цін — витягуємо число з рядка ціни за допомогою регулярного виразу та наступною заміною коми. Конвертуємо валюту за курсом НБУ або фіксованим значенням. Округлюємо до двох знаків.
Нормалізація характеристик — одиниці виміру парсяться через /^([\d.,]+)\s*([а-яА-Яa-zA-Z]+)$/u, булеві значення приводяться до Y/N, спискові властивості маппяться на XML_ID через конфігураційний масив.
Обробка зображень — часто парсери качають картинки з дублюючими іменами. Ми обчислюємо md5-хеш кожного файлу і порівнюємо з уже завантаженими. Якщо хеш збігається — картинка не додається. Це запобігає розростанню файлового сховища і прискорює імпорт. Також налаштовуємо автоматичну генерацію прев'юшок через Bitrix Imaging.
Як мапити категорії без ризику?
Структура категорій джерела рідко збігається з розділами інфоблоку. Використовуємо таблицю відповідностей:
$categoryMap = [ 'Електроінструмент/Дрелі' => 15, 'Електроінструмент/Шуруповерти' => 16, 'Ручний інструмент/Викрутки' => 22, ]; $sectionId = $categoryMap[$externalCategory] ?? DEFAULT_SECTION_ID; Для нових категорій, відсутніх у маппінгу, товари поміщаються в розділ «Без категорії» із записом у лог. Автоматичне створення розділів небезпечне — одна помилка в даних джерела, і в каталозі з'являються сміттєві розділи. Наш досвід показує, що такий підхід скорочує час на підтримку каталогу в рази.
Чому валідація обов'язкова перед імпортом?
Навіть після трансформації дані можуть містити помилки: пусте ім'я, невірний XML_ID, від'ємна ціна. Валідація — це окремий етап пайплайну між трансформацією та імпортом:
| Поле | Правило | Дія при порушенні |
|---|---|---|
| NAME | Не пусте, 3–255 символів | Пропустити елемент, записати в лог |
| XML_ID | Унікальне, не пусте | Пропустити (дубль) |
| PRICE | Число > 0 | Встановити 0, позначити для перевірки |
| SECTION_ID | Існуючий розділ | Помістити в «Без категорії» |
| PREVIEW_PICTURE | Файл існує, розмір < 10 МБ | Імпортувати без картинки |
Усі відхилені елементи зберігаються в таблиці parser_rejected із причиною. Це дає можливість розібрати помилки без повторного імпорту.
Що входить у налаштування трансформації під ключ?
- Аудит вихідних даних та виявлення типових проблем.
- Проектування ланцюжків правил для кожного поля.
- Реалізація на PHP з використанням
\Bitrix\Main\ORMта подій. - Інтеграція з існуючим парсером або імпортером.
- Тестування на реальній вибірці товарів (мінімум 1000 позицій).
- Документація за правилами та інструкція для внесення змін.
- Гарантія 12 місяців на код та підтримка при зміні джерела.
Детальніше про налаштування правил
Конфігурація правил дозволяє гнучко змінювати логіку без зміни коду.Приклад конфігурації правил:
$transformRules = [ 'NAME' => [ ['type' => 'trim'], ['type' => 'mb_title_case'], ['type' => 'max_length', 'value' => 255], ], 'PRICE' => [ ['type' => 'extract_number'], ['type' => 'multiply', 'value' => 1.2], // Націнка 20% ['type' => 'round', 'value' => 2], ], 'PROPERTY_WEIGHT' => [ ['type' => 'extract_number'], ['type' => 'convert_unit', 'from' => 'kg', 'to' => 'g'], ], ]; Порівняння: конфігурація vs зашита логіка
| Критерій | Конфігурація правил | Зашита логіка в коді |
|---|---|---|
| Час на зміну | 5 хвилин | 1–3 години + тести |
| Додаткові витрати | Немає | Можливі |
| Ризик помилок | Мінімальний | Високий |
| Прозорість | Видна в конфігу | Неявна |
Конфігурований підхід дозволяє змінювати трансформацію без залучення розробника та правки парсера. Для каталогів з частими змінами джерела це суттєво дешевше в довгостроковій перспективі. Таке налаштування окупається в середньому за 2-3 місяці, економлячи на ручній обробці.
Процес роботи та терміни
- Аналітика — вивчаємо структуру джерела, виявляємо критичні місця (1–2 дні).
- Проектування правил — створюємо конфігурацію під кожен тип поля (1–2 дні).
- Реалізація — пишемо класи-трансформери та валідатори (2–3 дні).
- Тестування — прогоняємо на реальних даних, виправляємо помилки (1 день).
- Деплой — розгортаємо на бойовому сервері, документуємо (1 день).
Орієнтовний термін — від 5 до 8 робочих днів. Підсумкова вартість розраховується індивідуально і залежить від кількості полів та складності трансформацій. Отримайте консультацію з налаштування трансформації вже сьогодні.
Чому ми не рекомендуємо автоматичне створення розділів?
Одного разу ми спостерігали, як парсер створив 500 розділів через невірне поле категорії в джерелі. Відновлення зайняло тиждень. Наш підхід — лише ручне або напівавтоматичне маппування з повідомленням адміністратора. Це підвищує надійність і дозволяє зберегти чистоту каталогу.
Наш досвід — 10+ років роботи з 1С-Бітрікс та більш ніж 500 проектів з інтеграції та парсингу. Офіційна документація Бітрікс рекомендує використовувати інфоблоки версії 2.0 і теговане кешування для великих каталогів. Ми дотримуємося цих рекомендацій і гарантуємо, що ваш каталог буде працювати швидко та без збоїв.
Зв'яжіться з нами — оцінимо ваш проект і підготуємо конфігурацію трансформації за 1–2 дні. Замовте налаштування трансформації та забудьте про проблеми з імпортом.