Why wholesale prices in Bitrix do not work in the cart
A large buyer fills a cart with dozens of items, but at checkout sees the retail price.
Order volume rules are set up in the system, but the cart calculation does not pick them up: the condition is tied to the product page or to a customer group, and the price is recalculated at the base price when the item is added and no longer updates when the quantity changes.
The second typical failure is the order in which conditions apply. Wholesale prices in Bitrix are often assembled from several independent mechanisms: volume discount, category discount, individual agreement with the client.
They are not coordinated with each other, so the rule that applied last wins, not the one that is more favorable to the buyer.
If you remove an item or drop below the threshold, the price does not return to the original, and the invoice total diverges from what the client saw in the cart.
The cost of such an error is manual recalculation of orders.
The manager opens every large checkout, checks the volume against the price list, edits lines manually: at scale this is dozens of operations per shift, invoice delay and discrepancies between the cart, document, and shipment.
Catalog caching is a separate obstacle — the updated price list does not reach the storefront until the cache is cleared, and the buyer continues to see the old price.
The causes are usually the same: the threshold matrix is not described, conditions are layered on top of the standard calculation, and there is no set of test scenarios for recalculation when the order composition changes. Next we analyze how this is addressed — from rule setup to testing on real orders.
What automatic calculation by order volume gives
Wholesale conditions stop being an agreement in chat and become part of the catalog: in Bitrix, the price type is tied to a customer group, and the threshold triggers by order amount or by the number of items in the cart. Verification happens when the product is added, not when it is agreed with the manager.
Recalculation is performed on the catalog side, so the final price and discount are visible to the buyer already in the cart — before the request is submitted.
This is automatic calculation by volume: the discount grows in steps, and on each next item the client sees how much to add to reach the next threshold.
Then the order goes to the accounting system with the price type already applied, so the invoice, shipment, and document match in amounts and items.
Manual invoice editing after checkout is the most common source of discrepancies between what was promised to the client and what ended up in the delivery note.
The effect is visible in numbers: order processing speed increases because correspondence with recalculation disappears; the share of orders that the manager edits manually falls to isolated cases; shipment errors related to uncoordinated pricing disappear as a class.
Conditions for customer groups — wholesale, dealer, retail — are set separately and do not intersect.
Ways to set volume conditions: comparison of approaches
A volume condition can be set by several mechanisms, and they are not interchangeable: each has its own area of responsibility — from the cart to the accounting system.
The difference appears in where the rule is stored, at which step it triggers, and what breaks as the assortment and number of contracts grow.
| Option | When it fits | Limitations |
|---|---|---|
| Cart rules | Threshold is calculated based on the current order: amount, number of items, quantity of one product | Works only at checkout; cumulative conditions and deferred bonuses cannot be expressed |
| Customer groups | Condition is stable and tied to the client or channel: wholesale, dealer, retail | Thresholds are revised manually, the number of groups grows with the number of contracts |
| Separate price list | You need your own price grid and a separate storefront for the segment | Catalog duplication: prices and stock diverge with every update |
| Calculation from the accounting system | Price depends on accumulated volume, contract, and order history | Real-time data exchange is required: if the export is delayed, the website price becomes outdated |
The boundary between approaches lies at the moment when volume becomes known. Cart rules calculate based on the actual order, groups and price lists set the condition in advance, and the accounting system derives it from accumulated history.
The schemes can be combined, but each rule must have one owner — otherwise, when an item is returned or partially cancelled, the price will be recalculated twice, and the buyer will see a discrepancy between the website and the invoice.
Setup stages: from catalog audit to handover
Wholesale price rules break not at the moment of setup, but at the decision stage: if thresholds and priorities are not fixed before work begins, managers get discrepancies with the calculation in 1C, and buyers get different prices for identical carts.
That is why we work according to a procedure: first we analyze the catalog structure and customer types, and only then enable the calculation.
- Audit of the catalog and customer types: review sections, trade offers and properties by which volume is determined, compare price types on the site with the 1C database, find items without price binding — they are the first to fail.
- Calculation rule scheme for approval: fix thresholds by quantity and amount, rule priority when they intersect, behavior at the threshold boundary, and the rounding method — before anything is enabled on the live catalog.
- Configure price levels and bind rules to sections and customer groups: one scale must not override another, and the price source is explicitly defined for each group.
- Run on a test environment: a copy of the catalog and exchange, scenarios for one unit, exactly at the threshold, threshold plus one, and a mixed cart, comparing the result with the manager's calculation.
- Transfer settings to the production environment: during a low-load window, with selective price verification by groups and a checklist of items where discrepancies previously occurred.
- Training and handover: a procedure for editing thresholds so the manager can change conditions without a developer, a description of the logic, and a change log.
Each stage closes with verification, so discrepancies are caught before rules are enabled, not after customer complaints.
What is included in the handover package: rules and procedures
Wholesale price rules work only as long as they can be handed over to another person. That is why implementation ends not with an enabled setting, but with a documentation package: using it, the manager, content editor, and site administrator can continue without us.
- Configured calculation rules: quantity thresholds, discount step, rule priority when conditions intersect, and cart behavior at boundary values.
- Customer profiles and binding of groups to price types — which category of clients sees which price in the catalog, product page, and checkout.
- Calculation scheme with examples on real carts: from the triggered threshold to the final order amount, including rounding and discount combination.
- Manager instructions: how to issue individual conditions outside the general grid, how to check the applied rule in an order, and what to do in case of condition conflict.
- Change procedure: who approves a new threshold, how an edit passes verification in the test environment, and at what point it reaches the production system.
- Reference maintenance procedure: how to add new product groups, what to update when supplier prices are revised, and how to mark rules whose validity period has expired.
- Rule version log with date and responsible person — to restore previous conditions if the new grid produced an unexpected result.
Such a package removes the main risk: knowledge of how the wholesale price is calculated stops living in chat and in one administrator's head, and changing a threshold becomes a procedural operation.
Case: how manual recalculation of large orders was removed
A wholesale supplier with several warehouses accepted orders through a personal account on 1C-Bitrix, but the volume discount lived not in the system, but in the manager's head: the transaction amount was calculated manually and entered into the invoice.
Every fifth large order went to the client with a recalculation — a pause from several hours to a day if the manager was on another call.
What changed
We configured wholesale price levels tied to the order volume in the cart: a threshold by item amount, a threshold by the number of units of one SKU, and separate conditions for product groups.
The rules are calculated server-side at checkout — the price is recalculated in the cart and fixed in the order, while manual editing of the amount requires a separate access right.
| Metric | Before implementation | After |
|---|---|---|
| Share of orders with manual price editing | about 18% | less than 1% |
| Time to process a request from checkout to invoice | up to 24 hours | minutes |
| Discrepancies between invoice and shipment | 6-9 per month | isolated |
Result
The metrics hold not because of stricter control, but because calculation became the only source of price: the invoice, shipment, and document in the accounting system are generated from one value.
This also closed the human factor — the manager can no longer ship at a price that is not in the rules.
What to do if wholesale conditions are already set up manually?
Manual rules rarely live in one place: a discount can be hardcoded in the customer card, in a user group, in individual contract terms, and in a customization that calculates the cart.
Rules layer on top of each other, no one remembers the order in which they apply, and editing one rate breaks the calculation for part of the wholesalers.
Therefore, we start with an inventory of settings: export all sources where a price is set at all — cart calculation rules, group bindings, contract terms, custom modifications in templates, exchange with the accounting system.
For each item, we record the trigger condition, owner, and priority. The result is a registry that shows which rules duplicate each other and which no longer trigger on any order.
We build the transition without downtime like this: the new calculation scheme works in parallel with the old one, and switching occurs only after reconciliation.
We run both calculations on real order history and analyze each discrepancy — price in the cart, total in the invoice, value in the shipment. As long as the figures do not match for all customer types, the previous mechanism remains operational.
We separately address backward compatibility. Agreements with specific customers are transferred as personal exceptions on top of the new rules, so the client does not see a different price in the next shipment. External exchange continues to output the same data in the previous form.
We schedule the switch itself in a window of minimum load and keep the old environment at hand for a quick rollback. This way wholesale prices move to a managed scheme, while current shipments and agreements with customers remain untouched.
Technical questions asked most often
Volume and cumulative discounts almost never exist alone: rules are divided by categories, amounts, and customer groups. The main doubts arise where conditions intersect or meet individual agreements. Let's review the default system behavior and what is configured for your process.
What wins if a volume discount intersects with a customer group discount?
Rules are arranged by weight: first individual counterparty conditions, then volume thresholds, then general promotions. The intersection is resolved not by the "largest discount," but by the defined priority order.
In the applied rules log for each order, you can see which condition triggered and which remained aside.
How is the total rounding calculated?
Rounding is configured separately for the line and for the order total, and the discount is calculated before or after tax — this changes the final amount.
The order is fixed in the rule itself, so the same cart always produces the same result, and the discrepancy with the manager's calculation is explainable and verifiable.
Is this compatible with contract terms?
Individual agreements have priority over automation: a personal rule is created for the counterparty that overrides general thresholds. Contract prices can be limited by term or shipment volume, and after it expires the system automatically returns to the standard grid.
Will the setup affect already placed orders?
Price and discount are fixed at the moment of checkout, so changing rules does not recalculate closed and current orders. Mass recalculation is performed only by a separate operation — we launch it deliberately, after approving the list.
Let's discuss the task — we'll come back with an estimate and plan
The first conversation is about data, not presentations.
To come back with a work estimate and implementation plan, we need to understand the catalog structure: how price types are organized, whether there are already quantity discounts, how the 1C export reaches the site, and what happens to the price in the cart.
From these inputs it is immediately clear whether exchange customization is needed or the task is covered by rules in the existing Bitrix environment.
- Catalog export: how many products and trade offers, whether there are variants by color, size, packaging.
- Current price types and discount rules: by volume in units, by order amount, or by categories.
- Price source: 1C export, manual entry, supplier price list — and how often it is updated.
- Examples of real orders: which volumes are considered wholesale and how the price should change at each step.
- Display requirements: show the discount scale on the product page and in the cart, calculate the price immediately or after manager confirmation.
- Roles and access: who approves wholesale prices, who sees them before publication, whether separate conditions are needed for customer groups.
- Exchange scheme: how often prices and stock are synchronized, what to do in case of discrepancy, and who is responsible for data conflict.
If something from the list is not at hand — no problem, we'll assemble it together: usually a catalog export and a short conversation with the person who manages the price list are enough.
Describe the task, indicate where it hurts now — and we will come back with a work estimate, implementation order, and points where your verification is needed.
