Автоматичний збір залишків з вітрин постачальників у 1С-Бітрікс
Ситуація: постачальник не дає API, прайс-листи надсилає раз на тиждень поштою, а реальні залишки змінюються щодня. Покупець оформлює замовлення — товару немає. Ми вирішуємо цю проблему парсингом вітрини постачальника з оновленням поля CATALOG_QUANTITY у 1С-Бітрікс. Парсинг — це не завжди HTML: часто залишки лежать у JSON-змінних на сторінці (window.__PRODUCT_DATA__). Використовуємо CURL і regex — це швидше за headless-браузер і не навантажує сервер. Для захисту від блокувань застосовуємо випадкові User-Agent і ротацію проксі. За 5 років на ринку автоматизували збір залишків для каталогів від 500 до 50 000 SKU. Кожен проект проходить індивідуальне налаштування — від вибору методу парсингу до логіки обробки нульових залишків. Замовте розробку парсингу — і ми безкоштовно проаналізуємо вітрину вашого постачальника.
Як парсимо залишки з сайтів постачальників
На сайті постачальника залишок може бути представлений по-різному: числове значення (в наявності: 47 шт) — прямо парсимо число; статус наявності (в наявності, під замовлення, немає) — мапимо на 0/1/999; декілька складів — підсумовуємо або беремо найближчий склад. Іноді залишки ховаються в JS-змінних — шукаємо через regex у тілі сторінки, це швидше за headless-браузер. Якщо постачальник використовує API (рідко), підключаємося через REST.
Чому мапінг товарів — найвужче місце?
Ключовий етап. Без надійного мапінгу парсинг марний. Варіанти:
- Артикул постачальника — додаємо властивість
SUPPLIER_SKUв інфоблок. При парсингу шукаємо елемент з цим значенням черезCIBlockElement::GetList()з фільтром за властивістю. - XML_ID — якщо раніше імпортували товари з прайсу постачальника, XML_ID може збігатися з його внутрішнім ID.
- EAN/штрихкод — універсальний варіант для брендових товарів.
Для великих каталогів (10 000+ SKU) фільтрація за властивістю через ORM працює повільно. Краще побудувати зворотний мапінг supplier_sku → element_id у Redis або в кастомній таблиці та оновлювати його при змінах каталогу.
Як оновлюються залишки в Бітрікс
Згідно з документацією 1С-Бітрікс, оновлення кількості товару виконується через метод CCatalogProduct::Update.
CCatalogProduct::Update($elementId, [ 'QUANTITY' => $parsedQty, 'QUANTITY_RESERVED' => 0, ]); Якщо магазин використовує склади (b_catalog_store), оновлюємо через CCatalogStoreProduct::Update() із зазначенням STORE_ID.
При оновленні лише кількості не чіпайте ACTIVE — інакше втратите ручні правки активності. Робіть окремий UPDATE лише потрібного поля.
Як обробляти нульові залишки без втрати продажів?
Не варто автоматично приховувати товар при нульовому залишку — можливо, постачальник поповнить склад через день. Правильна щадна логіка:
- Кількість = 0 → товар залишається активним, але додається прапорець «під замовлення».
- Кількість = 0 більше N днів → повідомлення менеджеру, ручне рішення.
- Товар не знайдено на сайті постачальника 3+ рази поспіль → прапорець
SUPPLIER_DISCONTINUED.
Прапорці реалізуємо через властивості інфоблоку або поля Highload-блоку.
Як налаштувати парсинг залишків: покрокова інструкція
- Аналіз вітрини постачальника. Визначаємо спосіб парсингу (HTML, JSON-змінні, API), готуємо селектори.
- Розробка парсера. PHP-скрипт з підтримкою CURL, regex, опціонально Guzzle. Для захисту від блокувань використовуємо випадкові User-Agent і проксі.
- Налаштування мапінгу SKU. Зв'язка артикулів постачальника з ID товарів у Бітрікс. Для каталогів 10 000+ SKU використовуємо Redis.
- Інтеграція в Бітрікс. Агент або cron-задача, оновлення залишків через
CCatalogProduct::Update(). Перевіряємо на тестовому наборі товарів. - Логіка обробки нульових залишків. Автоматичні прапорці, повідомлення менеджеру. Тестуємо сценарії: товар зник, з'явився, змінилася ціна.
- Моніторинг і підтримка. Після запуску парсер працює стабільно; при зміні структури сайту постачальника адаптація займає не більше пари годин.
Що входить у роботу
| Компонент | Опис |
|---|---|
| Аналіз вітрини постачальника | Визначаємо спосіб парсингу (HTML, JSON-змінні, API), готуємо селектори |
| Розробка парсера | PHP-скрипт з підтримкою CURL, regex, опціонально Guzzle |
| Мапінг SKU | Зв'язка артикулів постачальника з ID товарів у Бітрікс |
| Інтеграція в Бітрікс | Агент або cron-задача, оновлення залишків через CCatalogProduct::Update() |
| Логіка обробки нульових залишків | Автоматичні прапорці, повідомлення менеджеру |
| Документація та підтримка | Схема мапінгу, інструкція з додавання постачальника, 2 тижні безкоштовної підтримки |
Таймлайн робіт
| Етап | Термін |
|---|---|
| Аналіз сайту постачальника, вибір методу парсингу | 2–4 години |
| Розробка парсера залишків | 1–2 дні |
| Налаштування мапінгу SKU | 4–8 годин |
| Логіка оновлення в Бітрікс + обробка нульових залишків | 4–8 годин |
| Налаштування розкладу та моніторингу | 2–4 години |
Разом: 3–5 робочих днів на одного постачальника. Кожен додатковий постачальник — +1–2 дні (різна структура сайтів).
Ми гарантуємо, що після запуску парсинг працюватиме стабільно, а при зміні структури сайту постачальника адаптація займе не більше пари годин. Економія часу на ручній обробці залишків — до 80% на місяць. Оцінимо ваш проект безкоштовно — просто напишіть нам. Отримайте консультацію прямо зараз.