Автоматичне створення товарних фідів для інтернет-магазину на 1С-Бітрікс

Маркетолог виявляє, що фід для Яндекс.Маркету оновлюється раз на добу через ручний експорт, а ціни в каталозі змінюються кілька разів на день через вивантаження з 1С. У результаті на маркетплейсі показуються неактуальні ціни — покупці клікають, бачать іншу вартість і йдуть. Стандартний модуль експорту catalog.export справляється з базовими випадками, але при нестандартних вимогах (кілька складів, кастомні властивості, регіональні умови) впирається в обмеження. На одному з проектів з каталогом на 50 000 товарів розбіжність цін сягала 15%, що призводило до 30% відмов від покупок. Тільки після впровадження кастомного модуля з інкрементальним оновленням проблема була вирішена. Наш досвід налічує понад 30 успішних проектів. Гарантуємо коректну обробку залишків та відсутність дублів. Економія на ручному експорті становить до 40% бюджету. Вартість розробки — від $1500 за базовий модуль під ключ.

Чому стандартний експорт не підходить для генерації фідів?

Стандартний модуль catalog.export не підтримує:

• Множинні склади з роздільними залишками.
• Кастомні властивості для різних каналів (наприклад, condition для Google Merchant).
• Регіональні ціни та знижки.
• Інкрементальне оновлення — доводиться генерувати повний фід щоразу, що на 50 000 товарів займає 5–10 хвилин і навантажує сервер.

Ці обмеження ведуть до ручного експорту, помилок і неактуальних даних. Кастомний модуль вирішує всі завдання. Він працює в 10 разів швидше за стандартний експорт завдяки потоковій генерації, а інкрементальне оновлення в 5 разів швидше за повну перегенерацію.

Як влаштований модуль генерації фідів?

Основне завдання — зробити генерацію швидкою, гнучкою та автоматичною. Модуль будується навколо трьох компонентів: рушія шаблонів фідів, планувальника оновлень та реєстру форматів.

Реєстр форматів зберігає конфігурації для кожного каналу: Яндекс.Маркет (YML), Google Merchant (XML/CSV), ВКонтакте, Avito, Ozon, власний формат клієнта. Кожен формат описується PHP-класом, що реалізує інтерфейс FeedFormatInterface:

interface FeedFormatInterface { public function getHeader(): string; public function renderOffer(array $element, array $prices): string; public function getFooter(): string; public function getMimeType(): string; } 

Це дозволяє додавати нові формати, не чіпаючи ядро генератора. Детальніше про формат YML — в Wikipedia.

Генератор працює потоково: дані читаються з b_iblock_element, b_catalog_price, b_catalog_product через DataManager::getList з пагінацією (батчі по 500 елементів), негайно записуються у файл через fwrite. Генерація фіда з 50 000 товарів не потребує 512 МБ пам'яті. Фінальний файл атомарно замінює попередній (rename), тому краулер не отримує частково записаний документ.

Як працюють резолвери цін і залишків?

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

Модуль реалізує резолвер цін — стратегію, що обирає підсумкову ціну за набором правил:

$priceResolver = new PriceResolver([ new DiscountRule($userId), // застосувати знижки через Sale\Discount new RegionPriceRule($regionCode), // регіональна надбавка new MinPriceRule(), // взяти мінімум серед груп цін ]); $finalPrice = $priceResolver->resolve($productId); 

Залишки по складах. Для Ozon та інших майданчиків потрібно вказувати залишки за конкретними складами (b_catalog_store_product). Модуль агрегує залишки по кількох складах (до 50), застосовує резерви з b_sale_basket та виводить коректну доступну кількість.

Фільтрація товарів. Через інтерфейс модуля задаються умови: тільки товари з ненульовим залишком, певні розділи, виключення за властивістю CML2_EXPORT = N. Умови компілюються у фільтр для CIBlockElement::GetList.

Що таке інкрементальне оновлення?

Повна перегенерація фіда з 50 000 позицій займає 3–5 хвилин. Для частого оновлення цін це неприйнятно. Модуль підтримує інкрементальний режим: через подію OnAfterCatalogPriceUpdate фіксуються змінені товари, і раз на 15 хвилин агент перегенерує лише їх рядки у фіді через partial-update з тимчасовим файлом та патчингом. Таке оновлення в 10 разів швидше за повну перегенерацію. Подія описана в документації Бітрікс.

Як моніторинг допомагає в роботі модуля генерації фідів?

Модуль веде таблицю myvendor_feed_log з історією генерацій: час початку/завершення, кількість елементів, розмір файлу, помилки. В адмін-інтерфейсі виводиться дашборд: коли оновлювався кожен фід, скільки товарів потрапило у вивантаження, які відфільтровані та чому. Це дозволяє швидко виявляти проблеми з даними або конфігурацією.

Типові помилки при налаштуванні фідів та їх усунення

• Неправильні URL зображень (не HTTPS) — перевірте протокол у властивостях.
• Відсутній ідентифікатор товару у форматі vendorCode — додайте відповідну властивість.
• Завищений ціновий ліміт на майданчику — знизьте ціну або отримайте дозвіл.
• Некоректна прив'язка категорій — синхронізуйте з категоріями майданчика.
• Відсутність обов'язкових полів (наприклад, condition для Google Merchant) — додайте у шаблон.

Що входить в роботу?

• Документація по архітектурі модуля та API.
• Доступ до вихідного коду модуля на GitHub.
• Навчання адміністраторів роботі з адмін-панеллю.
• Гарантійна підтримка 1 місяць (оновлення, баг-фікси).
• Консультації протягом 3 місяців після здачі.

Порівняння стандартного та кастомного модуля

Терміни розробки

Терміни та вартість можуть бути скориговані після аналізу вашого каталогу. Для точної оцінки пишіть нам — оцінимо проект безкоштовно. Конфігурація торгового каталогу (ціни, структура складів, наявність торгових пропозицій) повинна бути зафіксована до початку розробки.

Звертайтеся! Розробимо модуль під ключ за 2–10 тижнів залежно від складності. У вартість входить документація, навчання та місяць підтримки.