Setting up promotional prices according to the 1C-Bitrix schedule

Setting up promotional prices by schedule in 1C-Bitrix

Manager wants to launch a discount on Friday at 18:00 and remove it on Monday at 09:00 — without manual intervention. The catalog module supports date-range discounts, but in practice setup breaks due to wrong discount type selection, cache ignoring, and conflicts between cart rules and catalog logic.

Two discount mechanisms: catalog vs. cart

Two discount engines run in parallel in Bitrix, and confusing them is the main mistake.

Catalog discounts (b_catalog_discount) — applied at price display stage. Have ACTIVE_FROM and ACTIVE_TO fields that set the period. Work with price types, user groups, and product property conditions. This is exactly the mechanism needed for scheduling.

Cart rules (b_sale_discount) — applied when calculating order in the sale module. Also have ACTIVE_FROM/ACTIVE_TO, but work differently: condition is checked at checkout time, not display. If promotional price should be visible in catalog before adding to cart — use catalog discounts.

Setting up catalog discount by schedule

Path: Shop → Product Discounts → Add discount.

Key fields:

• Active — must be "Yes".
• Start date / End date — set promotion window. Format depends on site settings, internally stored as DATETIME in b_catalog_discount.
• Discount type — percent or fixed amount.
• Application conditions — catalog section, specific products (by ID or property), user group.
• Priority — number determining application order. Discount with priority 1 applies before priority 2.

"Stop applying further discounts" flag — if enabled, discounts with lower priority won't apply. Use it to prevent promotional price from summing with loyalty discount.

Automation through agents

For complex schedules (every Friday, first day of month) ACTIVE_FROM/ACTIVE_TO fields aren't enough — they set one-time period. Solution — agent that programmatically creates and deactivates discounts.

Agent is registered in b_agent and calls \Bitrix\Catalog\DiscountTable::update() to change ACTIVE_FROM, ACTIVE_TO, and ACTIVE fields. Schedule is stored in custom table or in UF-fields of discount.

Alternative — cron script that uses schedule table (custom_discount_schedule) to find discounts to activate and flips ACTIVE flag. This approach is easier to debug: script log will show exactly what activated and when.

Caching and display

Catalog discounts are cached by catalog.section and catalog.element components. If cache TTL is 3600 seconds and promotion starts at 18:00, visitor might see old price until 19:00.

Solutions:

• Reduce TTL to 300–600 seconds during promotion period.
• Clear cache programmatically in agent after activating discount: \Bitrix\Main\Data\Cache::clearCache(true, '/bitrix/catalog.section/').
• Use tagged cache — when discount changes, catalog module clears tag catalog, but only if discount changed through API, not direct SQL.

Strikethrough old price displays automatically if price type has "old price" set and component template supports OLD_PRICE output. Check that catalog template outputs both values — otherwise visitor won't see the benefit.