Маркетолог обнаруживает, что фид для Яндекс.Маркета обновляется раз в сутки через ручной экспорт, а цены в каталоге меняются несколько раз в день из-за выгрузки из 1С. В итоге на маркетплейсе показываются неактуальные цены — покупатели кликают, видят другую стоимость и уходят. Стандартный модуль экспорта Битрикс (catalog.export) справляется с базовыми случаями, но при нестандартных требованиях (несколько складов, кастомные свойства, региональные условия) упирается в ограничения. На одном из проектов с каталогом на 50 000 товаров расхождение цен достигало 15%, что приводило к 30% отказов от покупок. Только после внедрения кастомного модуля с инкрементальным обновлением проблема была решена. Наш опыт насчитывает более 30 успешных проектов. Гарантируем корректную обработку остатков и отсутствие дублей. Свяжитесь с нами — разработаем модуль под вашу специфику.
Почему стандартный экспорт не подходит для генерации фидов?
Стандартный модуль catalog.export не поддерживает:
- Множественные склады с раздельными остатками.
- Кастомные свойства для разных каналов (например,
conditionдля Google Merchant). - Региональные цены и скидки.
- Инкрементальное обновление — приходится генерировать полный фид каждый раз, что на 50 000 товаров занимает 5–10 минут и грузит сервер.
Эти ограничения ведут к ручному экспорту, ошибкам и неактуальным данным. Кастомный модуль решает все задачи.
Как устроен модуль генерации фидов?
Основная задача — сделать генерацию быстрой, гибкой и автоматической. Модуль строится вокруг трёх компонентов: движка шаблонов фидов, планировщика обновлений и реестра форматов.
Реестр форматов хранит конфигурации для каждого канала: Яндекс.Маркет (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).Процесс разработки модуля
- Аудит текущего каталога и требований к фидам.
- Проектирование архитектуры модуля (резолверы, форматы, кэширование).
- Разработка и интеграция модуля на вашем проекте.
- Настройка агентов и планировщика для автоматической генерации.
- Тестирование на реальных данных и корректировка.
- Передача документации и обучение администраторов.
- Гарантийная поддержка 1 месяц.
Сравнение стандартного и кастомного модуля
| Критерий | Стандартный модуль | Кастомный модуль |
|---|---|---|
| Инкрементальное обновление | Нет | Да, через агенты |
| Поддержка нескольких форматов | Ограниченно | Любые (YML, XML, CSV, JSON) |
| Гибкая фильтрация товаров | Минимальная | По свойствам, разделам, остаткам, регионам |
| Резолвер цен | Только основная цена | Множественные стратегии |
| Мониторинг и логирование | Нет | Да, с дашбордом |
| Требования к памяти | Высокие (полная загрузка) | Низкие (потоковая запись) |
Сроки разработки
| Объём | Состав | Срок |
|---|---|---|
| Базовый | 1 формат (YML или GMC) + планировщик | 2–3 недели |
| Средний | 3–5 форматов + резолвер цен + остатки | 4–6 недель |
| Расширенный | + инкрементальное обновление + мониторинг + регионы | 7–10 недель |
Сроки могут быть скорректированы после анализа вашего каталога. Для точной оценки свяжитесь с нами — получите консультацию по вашему проекту. Конфигурация торгового каталога (цены, структура складов, наличие торговых предложений) должна быть зафиксирована до начала разработки.







