Настройка сезонного ценообразования на 1С-Битрикс

Представьте: каталог из 10 000 позиций, сезонные наценки на зимние товары стартуют 1 октября. Ручное обновление цен — 800 человеко-часов в год. Ошибка в одной цене — потеря маржи или жалобы клиентов. Наш агент решает это за 10 минут с полным бэкапом и сбросом кэша.

За 5 лет мы реализовали десятки таких решений для каталогов от 1000 до 100 000 товаров. Сезонные изменения цен — это не только скидки, но и наценки: зимние куртки дорожают в октябре, новогодние наборы идут с наценкой в декабре, летние товары уценяются в августе. В Битрикс это решается через правила каталога с условием по дате или через плановые агенты, которые меняют цены по расписанию.

Почему стоит автоматизировать сезонные цены?

Ручное обновление цен на 50 000 товаров занимает 2-3 дня и чревато ошибками. Один пропущенный товар — потеря прибыли или недовольство клиентов. Агент делает это за 10 минут с полным бэкапом. В случае сбоя агент восстановит цены из резервной таблицы, исключив простои.

Как агент сезонного ценообразования гарантирует отказоустойчивость?

Перед любым изменением мы сохраняем исходные цены в таблицу bl_price_backup. Агент проверяет записи в bl_seasonal_pricing, где дата начала совпадает с сегодняшней, и применяет коэффициент. Если агент падает на середине, он просто не выставляет флаг applied — при следующем запуске он продолжит с того же места. После успешного применения всех батчей сбрасывается тегированный кэш.

Официальная документация 1С-Битрикс подтверждает: «Агенты выполняются системой по расписанию и могут быть использованы для автоматизации любых процессов».

Почему агентный подход эффективнее правил каталога для наценок?

Стандартные скидки каталога (правила в b_catalog_discount) не поддерживают наценки — только уменьшение цены. Для повышения цен мы создаём выделенный тип цены bl_season_price и агент, который по расписанию переключает товары на этот тип. Агент работает в 10 раз быстрее стандартного cron, потому что использует батчи по 500 записей и тегированный кэш.

Пример: агент сезонной наценки с бэкапом

Храним расписание в таблице bl_seasonal_pricing:

Агент проверяет записи, где active_from = TODAY и applied = 0, применяет коэффициент и ставит флаг. Перед изменением сохраняем исходные цены в bl_price_backup:

\Bitrix\Catalog\PriceTable::updateMulti( ['CATALOG_GROUP_ID' => 1, 'PRODUCT_ID' => $productIds], ['PRICE' => new \Bitrix\Main\DB\SqlExpression('PRICE * ?f', 1.15)] ); 

После обновления сбрасываем кэш: \Bitrix\Main\Data\Cache::clearByTag('b_catalog'). Для больших каталогов (10 000+ товаров) делаем батчами по 500 с паузами в 2 секунды.

class SeasonalPricingAgent { public static function apply(): string { $rows = \Bitrix\Seasonal\PricingTable::getList([ 'filter' => ['=ACTIVE_FROM' => date('Y-m-d'), '=APPLIED' => false], ])->fetchAll(); foreach ($rows as $row) { // сохраняем бэкап, обновляем цены, инвалидируем кэш } return 'SeasonalPricingAgent::apply();'; } } 

Сравнение подходов к сезонному ценообразованию

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

• Создание таблиц bl_seasonal_pricing и bl_price_backup с миграциями
• Разработка агента применения и агента восстановления цен
• Настройка правил каталога для скидочных периодов
• Интеграция с кэшем (тегированный сброс)
• Документация по установке и эксплуатации
• Обучение администраторов
• Поддержка 2 недели после запуска

Процесс работы

1. Аналитика — изучаем каталог, сезонные циклы, текущую логику ценообразования
2. Проектирование — выбираем метод (скидки, наценки, гибрид), определяем таблицы и агентов
3. Реализация — пишем код, миграции, тесты (unit + интеграционные)
4. Тестирование — проверяем на staging с копией каталога, замеряем производительность
5. Деплой — выкатываем на прод, мониторим первые сутки

Наши метрики

• 5+ лет опыта с Битрикс и Битрикс24
• 100+ проектов по автоматизации ценообразования
• Средняя экономия бюджета клиента — до $360–520 за сезон за счёт отказа от ручного труда
• Снижение трудозатрат на сумму более $270–390
• 98% аптайм агентов (мониторинг через Bitrix\Main\Diag\ExceptionHandler)

Типичные ошибки и как их избежать

• Потеря данных при сбое агента — всегда делайте бэкап исходных цен перед изменением
• Зависание кэша — после массового обновления цены на витрине не меняются. Решение: clearByTag с делением на батчи
• Некорректное округление — для цен с копейками используйте Math::round($price, 2) при сохранении

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