Налаштування трансформації даних при парсингу для 1С-Бітрікс

При парсингу даних для каталогу 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, від'ємна ціна. Валідація — це окремий етап пайплайну між трансформацією та імпортом:

Усі відхилені елементи зберігаються в таблиці 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 зашита логіка

Конфігурований підхід дозволяє змінювати трансформацію без залучення розробника та правки парсера. Для каталогів з частими змінами джерела це суттєво дешевше в довгостроковій перспективі. Таке налаштування окупається в середньому за 2-3 місяці, економлячи на ручній обробці.

Процес роботи та терміни

1. Аналітика — вивчаємо структуру джерела, виявляємо критичні місця (1–2 дні).
2. Проектування правил — створюємо конфігурацію під кожен тип поля (1–2 дні).
3. Реалізація — пишемо класи-трансформери та валідатори (2–3 дні).
4. Тестування — прогоняємо на реальних даних, виправляємо помилки (1 день).
5. Деплой — розгортаємо на бойовому сервері, документуємо (1 день).

Орієнтовний термін — від 5 до 8 робочих днів. Підсумкова вартість розраховується індивідуально і залежить від кількості полів та складності трансформацій. Отримайте консультацію з налаштування трансформації вже сьогодні.

Чому ми не рекомендуємо автоматичне створення розділів?

Одного разу ми спостерігали, як парсер створив 500 розділів через невірне поле категорії в джерелі. Відновлення зайняло тиждень. Наш підхід — лише ручне або напівавтоматичне маппування з повідомленням адміністратора. Це підвищує надійність і дозволяє зберегти чистоту каталогу.

Наш досвід — 10+ років роботи з 1С-Бітрікс та більш ніж 500 проектів з інтеграції та парсингу. Офіційна документація Бітрікс рекомендує використовувати інфоблоки версії 2.0 і теговане кешування для великих каталогів. Ми дотримуємося цих рекомендацій і гарантуємо, що ваш каталог буде працювати швидко та без збоїв.

Зв'яжіться з нами — оцінимо ваш проект і підготуємо конфігурацію трансформації за 1–2 дні. Замовте налаштування трансформації та забудьте про проблеми з імпортом.

З чого почати розробку парсера для 1С-Бітрікс?

XMLReader, а не SimpleXML — вибір інструмента визначає долю проекту. SimpleXML завантажує весь XML у пам’ять, і при файлі постачальника на 800 МБ PHP впаде з fatal error на ліміті 512 МБ. XMLReader обробляє потоково, node за node, споживаючи 20–30 МБ — в 30 разів ефективніше. З цієї деталі стартує будь-яка розробка парсерів під Бітрікс. Ми робимо такі системи вже понад 10 років, реалізували 50+ проектів, і жоден не обходиться без правильного вибору парсера.

Проблеми, які вирішує парсинг

• Первинне наповнення каталогу — 15 000 карток з описами, характеристиками, фото. Вручну це три місяці контент-менеджера; парсер — тиждень з налагодженням. Економія часу — до 90%.
• Моніторинг цін конкурентів — збір даних з Ozon, Wildberries, сайтів конкурентів. Конкурент знизив ціну на ходову позицію — дізнаєтеся через дві години, а не через два тижні. Окупається за 2–3 місяці.
• Агрегація постачальників — п’ять прайсів у різних форматах (CSV з CP1251, XML у CommerceML, Excel з об’єднаними комірками) перетворюються на єдиний каталог із загальною системою властивостей інфоблоку.
• Збагачення карток — підтягуємо характеристики, інструкції, 3D-моделі з сайтів виробників. Без цього картка товару — пустушка для SEO.
• Оновлення асортименту — товари, які зникли з фіду постачальника, деактивуються через CIBlockElement::Update($ID, ['ACTIVE' => 'N']). Нові — створюються. Каталог синхронізовано.

Інструменти для розробки парсерів

Статичні сайти — PHP (Goutte, Symfony DomCrawler) або Python (Scrapy, lxml). Швидкість: 50–100 сторінок/сек. Вистачає для каталогів без JS-рендерингу.

SPA та динамічні сайти — Puppeteer або Playwright. Нескінченний скрол, AJAX-фільтри, lazy-load картинок — headless-браузер все це обробить. Швидкість падає до 1–10 сторінок/сек, але альтернативи немає: дані існують лише після виконання JavaScript.

Файли постачальників:

• Excel (XLS, XLSX) — PhpSpreadsheet. Обережно з об’єднаними комірками та формулами — вони ламають автоматичний мапінг.
• CSV — fgetcsv() з правильною кодуванням. Постачальники люблять CP1251, BOM у UTF-8 та крапку з комою замість коми. Все це потрібно детектувати та обробляти.
• XML/YML — XMLReader для великих файлів, SimpleXML для фідів до 50 МБ.
• CommerceML — стандартний формат обміну з 1С. Розбираємо import.xml та offers.xml, мапимо на структуру інфоблоків.

API — REST-ендпоінти постачальників, API маркетплейсів (Ozon Seller API, Wildberries API). Працюємо в рамках rate limits, обробляємо пагінацію.

Як влаштований пайплайн автонаповнення?

Чотири етапи. Кожен може зламатися по-своєму.

1. Збір. Парсер обходить джерела по cron-розкладу. Сирі дані пишемо в проміжну таблицю — не одразу в b_iblock_element. Логуємо все: скільки сторінок обійшли, скільки елементів розпарсили, де отримали 403 або timeout. Без логів налагодження парсера — ворожіння на кавовій гущі.

2. Нормалізація. Тут основна робота:

   • Очищення HTML-тегів, зайвих пробілів, Unicode-сміття
   • Одиниці виміру: «мм» → «мм», «millimeters» → «мм», «миллиметр» → «мм»
   • Мапінг категорій постачальника → розділи інфоблоку Бітрікс. В одного постачальника «Ноутбуки», в іншого «Ноутбуки та планшети», у третього «Laptops» — все в одну секцію
   • Дедуплікація за артикулом, EAN/GTIN. Один товар від трьох постачальників не повинен з’явитися тричі

3. Завантаження в Бітрікс. Через CIBlockElement::Add() для нових елементів, CIBlockElement::Update() для існуючих. Зображення: завантажуємо, ресайзимо через CFile::ResizeImageGet(), конвертуємо в WebP. Властивості — через CIBlockElement::SetPropertyValuesEx(). SEO-мета через \Bitrix\Iblock\InheritedProperty\ElementValues. ЧПУ генеруємо з транслітерації назви.

4. Оновлення. Ключовий момент — не затерти ручні правки контент-менеджера. Оновлюємо лише ціну, залишки, активність. Опис та фото, доопрацьовані вручну, позначаємо прапорцем UF_MANUAL_EDIT у властивостях елемента і пропускаємо при імпорті. Товари, що зникли з фіду — деактивуємо, але не видаляємо.

Моніторинг цін конкурентів: необхідність та реалізація

Окрема підсистема зі своєю специфікою:

Результат — дашборд: ваш товар vs конкуренти, історія цін, тренди. Менеджер бачить, де можна підняти ціну без втрати позиції, а де потрібно реагувати.

Модуль імпорту CSV/XML: налаштування під ваш формат

Для файлів від постачальників — кастомний модуль з адмінкою:

• Налаштовуваний мапінг: «колонка B у файлі → властивість BRAND інфоблоку»
• Автодетект кодування (CP1251, UTF-8, UTF-16) через mb_detect_encoding() з перевіркою
• Завантаження зображень за URL з чергою агентів Bitrix — щоб не забити канал
• Інкрементальне оновлення за хешем рядка: змінився рядок — оновлюємо, ні — пропускаємо
• Cron-розклад, звіт: створено 145, оновлено 892, помилок 3 (з деталями)

Великі файли: CSV обробляємо батчами по 1000 рядків через fgetcsv(), XML потоково через XMLReader, фонове виконання через чергу агентів Бітрікс — ніяких PHP-таймаутів.

Правова сторона — що важливо врахувати

• robots.txt — поважаємо. Crawl-delay — дотримуємося.
• Частота запитів — 1–2 в секунду, не більше. Не потрібно DDoS-ити чужий сайт.
• Контент виробників — використовуємо. Унікальні авторські тексти — не копіюємо.
• Персональні дані — не збираємо.

Що входить в розробку парсера під ключ?

Скільки часу займає розробка парсера?

Процес і терміни:

1. Прототип — парсер для 1–2 джерел за 2–3 дні. Оцінюємо якість даних, підводні камені (захист Cloudflare, капча, динамічне підвантаження).
2. Розробка — повний пайплайн: парсер → нормалізація → імпорт в Бітрікс → адмінка для управління.
3. Тестування — проганяємо на повному обсязі каталогу, перевіряємо edge-кейси (порожні поля, кривий HTML, биті картинки).
4. Запуск — налаштовуємо cron, моніторинг помилок через Telegram-бот.
5. Підтримка — конкурент переробив верстку? Оновлюємо CSS-селектори в парсері.

Отримайте консультацію: розкажіть про своє джерело даних — ми підберемо оптимальний підхід. Зв’яжіться для оцінки вашого проекту — запропонуємо рішення під ваш бюджет. Гарантуємо стабільну роботу парсерів і повну підтримку.