Why scheduled discounts in Bitrix break on a live catalog
The promotion rule fired on schedule, but the storefront still shows the old price.
The reason is usually that the catalog discount is not calculated at display time: recalculation runs in batches, indexing and page cache serve a previously assembled version, and the storefront lives its own life.
While the agent traverses the catalog, the customer has already opened the product page with the previous price — and promotional prices are not applied where they are most expected.
The second line of failures is price discrepancy between the storefront, cart, and order. The product page shows one amount, the cart recalculates it according to its own conditions, and the placed order records a third one or does not apply the discount at all.
Such a discrepancy surfaces in accounting and in disputes with the customer, not at the stage of setting up rules.
Some items remain with the old price for less obvious reasons as well: the rule does not cover trade offers, conflicts with another active rule, is limited by group or stock, and a long agent run is interrupted, so half the catalog simply fails to update.
Errors in catalog promotions accumulate silently — no one reads the log until sales come in at zero.
Then manual price recalculation begins: reconciling the export with the price list, selectively updating product pages, canceling and reissuing orders, and for rolling back a promotion — a new series of manual edits.
Below we break down how this is closed: from setting up rules and schedules to reconciling prices between the storefront, cart, and order.
What automation of promotional prices gives: measurable effect in practice
Automation of promotional prices in 1C-Bitrix changes not the storefront but measurable values: how much time goes into preparing a promotion, what share of catalog edits is done manually, and how many discrepancies between the product page and the placed order support catches.
While a promotion lives in a list of edits, launching it is an "night before launch" operation.
The key here is unified pricing rules. The period condition, priority between promotions, rounding order, and discount compatibility are set once and work identically on the product page, in the cart, and in the order.
This is why manual operations are reduced: the manager does not rewrite prices according to a procedure or return them back manually.
| Option | When it fits | Limitations |
|---|---|---|
| Discount on the product page | one-time edit for several items | does not scale; returning the old price is a source of errors |
| Cart rules with a validity period | seasonal promotions, categories, and product groups | requires control of priority and discount stacking |
| Separate price type for a promotion | different conditions for customer groups | more entities to maintain and export |
| External scheduled scenario | price calculation from stock and external data | requires coordinated exchange and a rollback plan |
The speed of rolling out a promotion after this is determined not by the number of items but by a single rule change. Price errors in an order are closed at the calculation level, not retroactively by reconciliation.
How to set up scheduled discounts in Bitrix: options and limitations
In 1C-Bitrix, price and discount live in different layers: a product condition, a cart condition, the trade offer price, and the price sent by the accounting system. The schedule switches them by time, but not every mechanism can start and end on its own.
Therefore, the choice here is not "what is easier to set up" but where exactly the price should take effect and who manages it. Let us compare four working options and their boundaries.
| Mechanism | When it fits | Limitations |
|---|---|---|
| Delayed catalog rules | A promotion with exact dates for a product group | Works by period and priority: when promotions overlap, higher priority wins, not the larger discount amount |
| Cart rules | The discount depends on amount, quantity, or product set | Calculated at checkout; the storefront price does not always change, and the condition is hard to show to the customer |
| Trade offer prices | Different price for product variants: size, color, bundle | The trade offers themselves are required; the schedule overwrites the base price, and it has to be restored in a separate step |
| Exchange with the accounting system | Promotions are set in the accounting system, the site only displays them | Depends on exchange regularity: between exports, the site price diverges from the accounting one |
In practice, a schedule is assembled from two layers: a catalog rule holds the period and priority, while a cart rule handles the logic of the set and amount.
Priority overlaps and return to the base price after the promotion ends are checked before launch — otherwise the discount either will not be removed or the wrong one will be removed.
Implementation order: from catalog analysis to result control
Scheduled discounts break not on the rules themselves but at the junction of price sources: some products come from the accounting system, some are edited manually, and some items have their own trade offers with separate stock.
Therefore, the order of work is fixed — first data inventory, then promotion logic, and only then enabling it on the production catalog.
- Catalog and price source audit. Which price types are used, who changes them and how, where the warehouse and site diverge. The output is an item map: what can be put into a promotion and what requires preliminary cleanup.
- Rule and priority scheme. List of promotions, enable/disable schedule, behavior when two discounts overlap, rules for products with zero stock.
- Mechanics setup. Linking rules to sections, properties, and brands, automatic return to the base price after the period ends. Done with standard catalog tools in 1C-Bitrix, without core modifications.
- Test environment. A copy of the catalog with real prices, where the schedule is run end to end: crossing the day boundary, the moment the promotion ends, a repeat launch. The storefront, cart, and placed order must show the same price.
- Promotion rule validation. Reconciliation on a control sample of products and in exports for aggregators and marketplaces — we catch discrepancies before enabling on the production catalog.
- Handover to operation. Launch procedure, instructions for the content manager, trigger log, and error notifications: the team launches the next promotion itself.
What remains in the project after handover: files, schemes, procedures
We hand over not an archive with code but a working loop: scheduled discount rules, the price flow scheme, procedures, and access. Using these artifacts, the content manager launches the promotion, not the developer — and every step is reproducible without us.
We record the composition in a handover act: we check every item on a test product so that the rule works for the customer, not only for us.
- Configured promotion rules — linking to product groups, sections, and sales channels, scheduled validity windows, priority when several promotions overlap.
- Price source scheme — where the rule takes the base price from: export from 1C, warehouse stock, manual edit; and what happens to the discount when the price list is updated.
- Promotion launch procedure — steps from approval to removal: checking on test items, enabling the window, storefront control, price return.
- Instructions for the content manager — how to enable, extend, or stop a promotion independently, which fields are required, what to do in case of rule conflict.
- Rule documentation — list of active rules, their priorities, and logic: why an old rule is disabled rather than deleted.
- Access rights to settings — roles: who changes prices, who only views, who approves; change log with author and edit time.
- Rollback scenario — how to return original prices in one operation if a promotion goes off plan, and where to view the trigger log.
Case: seasonal promotion on a catalog with tens of thousands of items
The catalog has several tens of thousands of product items, and the promotion is tied to the calendar: a seasonal sale, a holiday week, thematic collections.
Before automation, each wave of discounts was prepared manually — exporting the price list, editing the required rows line by line, and uploading them back into the catalog.
Before: manual promotion preparation
Preparation took about ten business days. About 3,800 items participated in the promotion, and in each wave 5–7% of rows went to the storefront with an incorrect price — after disabling the discount, the base price was not restored for all products.
The storefront and checkout showed different amounts, and some items dropped out of the promotion simply because no one got around to them.
After: rules and schedule
The calculation was moved into rules: condition groups by sections, brands, stock, and markup level, priority when rules overlap, an enable/disable schedule accurate to the minute, and automatic return of the base price when the promotion ends. The responsible employee now only checks the preview and confirms the launch.
Result: promotion preparation shrank from ten business days to two hours, manual edits went from 3,800 to zero, the share of items with an incorrect price fell to zero, and the transition to promotional prices happens without night-time gaps.
In 1C-Bitrix, such rules rely on the standard pricing mechanism, so the logic does not diverge from the exchange of the catalog, warehouse, and orders.
What to do if the catalog updates more often than promotion rules?
When an export from the accounting system arrives every 15 minutes, while promotion rules are recalculated once an hour, a mismatch window remains between the processes.
In this window, the storefront shows a price that is neither in the catalog nor in the promotion: the customer sees one amount, the manager in the order sees another.
The more often the catalog updates, the wider the window and the more discrepancies accumulate in orders and reports.
The cause is not the frequency of promotions but the fact that both processes live independently. The export writes base prices and stock, the promotion rule overwrites them according to its own schedule — and the result depends on which one ran last.
If the rule has already applied the discount and then the export arrives, the discount is erased until the next run; if the opposite, the promotion attaches to an item that has already been withdrawn from sale.
In 1C-Bitrix, standard agents and exchange with the accounting system are launched by different schedules, so the order has to be specified explicitly.
The working scheme is one managed price recalculation order instead of two independent schedules.
The export puts new prices into a queue, the handler accepts it in full, and only after that do the rules pass by priority: base prices, then promotional, then group and personal conditions.
Each step is idempotent and leaves a log entry — a repeat run does not double the discount and does not break already placed orders.
Rule priority is fixed explicitly. A conflict between two promotions for one product is resolved by rule seniority, not by the order of records in the database; period overlap is cut off at the setup stage, not at the moment of sale.
Reconciliation works separately: a report shows where the calculated price diverged from the one sent to the storefront — the discrepancy is visible immediately, rather than surfacing in a customer complaint.
A mass export can be paused for recalculation — the rule queues and runs immediately after it completes. This is cheaper than running a full catalog recalculation after every update.
Common technical questions before starting setup
Common questions before setting up a schedule are about the junctions where automation usually breaks: exchange with the accounting system, different product groups and regions, already placed orders, and storefront behavior at the moment of switching. Below are short engineering answers so the decision is made based on facts, not by feel.
We design the schedule as a separate layer on top of the catalog: promotion rules live as their own entity, and prices are recalculated in the background without blocking the storefront. Therefore, the start and end of a promotion do not become an event for the whole site.
How is the schedule synchronized with the accounting system?
Rules are linked to products by identifiers, not by names, so renaming an item does not break the promotion.
Exchange proceeds in portions, and the schedule applies the discount only to the confirmed catalog: if the export is delayed, the price will not "stick" to a nonexistent product. Stock and price remain consistent.
How are product groups and regions defined?
The rule is applied to a group or category as a whole, while exceptions are listed point by point — this way the promotion does not affect related items.
For regions, the condition is defined through the price type and warehouse binding: the discount is calculated separately for each type, so retail and wholesale do not conflict. When a new item appears in the group, it picks up the rule automatically.
What happens to orders placed during the promotion?
The price is fixed by a snapshot at the moment of checkout, so subsequent recalculation does not change the order. Orders created before the start are not recalculated retroactively.
For carts abandoned with a promotional price, a separate condition is defined — we calculate by checkout time, not by viewing time.
Will there be site downtime when enabling the schedule?
No. Recalculation proceeds in portions in the background, and the storefront at any moment serves either the previous or the new price — the customer will not see an empty price. Cache reset affects only changed groups, not the entire catalog.
If the promotion needs to be rolled back, the rule is removed with one action, and prices return to base.
Let's discuss the task: send the catalog structure and promotion rules
To come back with an estimate and work plan, rather than an approximate "three weeks, probably," we need a snapshot of your catalog and promotion rules.
Promotional prices live at the junction of the catalog, price types, and schedule, so the accuracy of the estimate directly depends on the composition of the data: the earlier the structure and overlaps are visible, the fewer assumptions remain in the estimate.
Send what you have on hand — even a partial set will speed up the review:
- Catalog structure: sections, products and trade offers, properties by which you group promotions — brand, collection, season, category.
- Composition of price data: which price types are used, where base and purchase prices come from, whether there are customer groups and cumulative discounts.
- Promotion rules: start and stop conditions, discount priority on overlap, what to do with a product that falls into several promotions at once.
- Schedule: intervals, time zone, recurrence, exceptions for holidays and sale periods.
- Data source: export from the accounting system, supplier price lists, manual manager edits — how often it changes and who is responsible for correctness.
- Rollback scenario: how you currently remove a promotion early and what happens to already placed orders.
- Access: test environment, catalog copy, business-side administrator contact.
Describe the task in two or three paragraphs and attach what you can find from the list — we will come back with an estimate and work plan: stages, timelines, responsibility areas, and points where your decisions are needed.