Автоматический сбор остатков с сайтов поставщиков в 1С-Битрикс

Наша компания занимается разработкой, поддержкой и обслуживанием решений на Битрикс и Битрикс24 любой сложности. От простых одностраничных сайтов до сложных интернет магазинов, CRM систем с интеграцией 1С и телефонии. Опыт разработчиков подтвержден сертификатами от вендора.
Услуги, которые мы предлагаем
Показано 1 из 1Все 1626 услуг
Автоматический сбор остатков с сайтов поставщиков в 1С-Битрикс
Средний
~1-2 недели
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1368
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    956
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Разработка на базе Битрикс, Битрикс24, 1С для компании Development of an Online Appointment Booking Widget for a Medical Center
    699
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    848
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    737
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    1086

Автоматический сбор остатков с витрин поставщиков в 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 только нужного поля.

Как обрабатывать нулевые остатки без потери продаж?

Не стоит автоматически скрывать товар при нулевом остатке — возможно, поставщик пополнит склад через день. Правильная щадящая логика:

  1. Количество = 0 → товар остаётся активным, но добавляется флаг «под заказ».
  2. Количество = 0 более N дней → уведомление менеджеру, ручное решение.
  3. Товар не найден на сайте поставщика 3+ раза подряд → флаг SUPPLIER_DISCONTINUED.

Флаги реализуем через свойства инфоблока или поля Highload-блока.

Как настроить парсинг остатков: пошаговая инструкция

  1. Анализ витрины поставщика. Определяем способ парсинга (HTML, JSON-переменные, API), готовим селекторы.
  2. Разработка парсера. PHP-скрипт с поддержкой CURL, regex, опционально Guzzle. Для защиты от блокировок используем случайные User-Agent и прокси.
  3. Настройка маппинга SKU. Связка артикулов поставщика с ID товаров в Битриксе. Для каталогов 10 000+ SKU используем Redis.
  4. Интеграция в Битрикс. Агент или cron-задача, обновление остатков через CCatalogProduct::Update(). Проверяем на тестовом наборе товаров.
  5. Логика обработки нулевых остатков. Автоматические флаги, уведомления менеджеру. Тестируем сценарии: товар исчез, появился, изменилась цена.
  6. Мониторинг и поддержка. После запуска парсер работает стабильно; при изменении структуры сайта поставщика адаптация занимает не более пары часов.

Что входит в работу

Компонент Описание
Анализ витрины поставщика Определяем способ парсинга (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% в месяц. Оценим ваш проект бесплатно — просто напишите нам. Получите консультацию прямо сейчас.

Разработка парсеров для 1С-Битрикс: с чего начать?

XMLReader, а не SimpleXML — выбор инструмента определяет судьбу проекта. SimpleXML загружает весь XML в память, и при файле поставщика на 800 МБ PHP упадёт с fatal error на лимите 512 МБ. XMLReader обрабатывает потоково, node за node, потребляя 20–30 МБ — в 30 раз эффективнее. С этой детали стартует любая разработка парсеров под Битрикс. Мы делаем такие системы уже 10+ лет, и ни один проект не обходится без правильного выбора парсера.

Какие проблемы решает парсинг?

  • Первичное наполнение каталога — 15 000 карточек с описаниями, характеристиками, фото. Вручную это три месяца контент-менеджера; парсер — неделя с отладкой.
  • Мониторинг цен конкурентов — сбор данных с Ozon, Wildberries, сайтов конкурентов. Конкурент снизил цену на ходовую позицию — узнаёте через два часа, а не через две недели.
  • Агрегация поставщиков — пять прайсов в разных форматах (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 в свойствах элемента и пропускаем при импорте. Товары, пропавшие из фида — деактивируем, но не удаляем.

Почему мониторинг цен конкурентов необходим?

Отдельная подсистема со своей спецификой:

Параметр Как устроено
Частота От раза в день до каждых 2 часов — зависит от волатильности рынка
Сопоставление По артикулу, EAN, нечёткое сравнение названий через расстояние Левенштейна
Хранение Своя таблица vendor_price_monitor с историей, не инфоблоки
Алерты Telegram/email при отклонении цены конкурента более чем на X%
Автоправила «Держать цену на 3% ниже минимальной среди конкурентов, но не ниже себестоимости + 15%»

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

Модуль импорта CSV/XML: настройка под ваш формат

Для файлов от поставщиков — кастомный модуль с админкой:

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

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

Правовая сторона — что важно учесть

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

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

Составляющая Описание
Прототип Парсер 1–2 источников за 2–3 дня для оценки качества данных
Основной парсер Полный сбор данных с одного источника (статический/динамический)
Модуль импорта в Битрикс Нормализация, загрузка, обновление, админка маппинга
Мониторинг цен Если требуется – система сбора и алертов (до 10 конкурентов)
Документация Описание архитектуры, инструкция по обновлению селекторов
Поддержка Гарантия 3 месяца на бесперебойную работу, правка при изменении вёрстки донора

Как мы работаем и сроки

  1. Прототип — парсер для 1–2 источников за 2–3 дня. Оцениваем качество данных, подводные камни (защита Cloudflare, капча, динамическая подгрузка).
  2. Разработка — полный пайплайн: парсер → нормализация → импорт в Битрикс → админка для управления.
  3. Тестирование — прогоняем на полном объёме каталога, проверяем edge-кейсы (пустые поля, кривой HTML, битые картинки).
  4. Запуск — настраиваем cron, мониторинг ошибок через Telegram-бот.
  5. Поддержка — конкурент переделал вёрстку? Обновляем CSS-селекторы в парсере.
Задача Сроки
Парсер одного сайта (статический HTML) 3–5 дней
Парсер SPA-сайта (Puppeteer/Playwright, обход защиты) 1–2 недели
Модуль импорта CSV/XML в Битрикс 1–2 недели
Система мониторинга цен (5–10 конкурентов) 2–4 недели
Комплексная система автонаполнения 4–8 недель
Поддержка и адаптация парсеров по подписке

Свяжитесь для оценки вашего проекта — мы предложим оптимальное решение под ваш бюджет. Гарантируем стабильную работу парсеров и полную поддержку в течение всего срока использования.