Why free delivery in 1C-Bitrix breaks order calculation
Classic failure: the customer fills the cart above the free shipping threshold, sees zero delivery cost, places the order — but in the invoice the amount with delivery comes back.
The reverse also happens: the threshold is formally reached, but the cart rule calculates the amount before discounts and gifts, while the order card calculates it after, and free delivery in 1C-Bitrix simply does not trigger.
From the outside it looks like “the site calculates incorrectly,” although internally three independent mechanisms operate that know nothing about each other.
The first is cart rules: this is where the free shipping threshold is set, and most often it is configured as a discount on the delivery service. The second is the service settings themselves: its base cost, restrictions by region, weight, and item dimensions.
The third is the shipping cost calculation module, which calls an external service and recalculates the result every time the cart contents change.
While the discount is applied earlier than the cost is calculated, there is nothing to discount: the amount is either zeroed out in the wrong place, or the discount is “eaten” by the next recalculation.
A separate source of errors in the cart is the recalculation order and caching of the result.
Delivery cost may remain from a previous state: the customer changed the address or receiving method, canceled some items — the threshold is no longer met, but the screen still shows zero.
Then the discrepancy goes into the exchange with 1C, and the manager corrects the invoice manually, explaining the difference to the customer.
The price of such a scheme is not cosmetics but lost orders and manual operations on every second checkout. Next we break down how this is closed.
What changes after setting up order shipping rules
Order shipping rules in 1C-Bitrix are described at the level of order conditions, not in the cart template: cart value threshold, restriction by delivery service, region, or product group.
Calculation runs server-side on every recalculation, so it behaves the same on the storefront, in the mobile version, and in one-step checkout.
Next — what changes in numbers. The threshold is visible right in the cart along with a hint about how much is missing until free delivery: the customer adds more goods instead of leaving to compare terms.
Average cart value grows, abandoned cart rate falls — provided that the hint updates together with the order contents.
Support requests decrease for two reasons. The customer no longer needs to write “why did delivery become paid” — the rule and discount trigger automatically.
The manager does not approve or apply the discount manually, and a whole class of errors disappears when free delivery was promised but remained paid in the order.
Checkout speed increases by eliminating extra steps: delivery cost recalculates without page reload, and the total is visible before confirmation.
The effect should be measured by a fixed set of metrics — average cart value, share of orders with free delivery, share of transitions from cart to payment, number of delivery-related requests. Comparing before and after setup separates the result of the new rules from seasonal fluctuations.
Ways to set up free delivery: comparison of approaches
Free delivery is not a separate toggle but a result of calculation: the module returns the cost, and then either the cart rule zeroes it out or a custom handler recalculates it.
Where the logic lives determines what will have to be changed as the number of services and regions grows.
| Option | When suitable | Limitations |
|---|---|---|
| Cart rule with delivery discount | One or two services, threshold by order amount | The discount is applied on top of the calculation; with several services the rule is duplicated, and region conditions are set manually as a list |
| Setting up the delivery calculation module | Thresholds and geography change often | Logic is tied to a specific handler — changing the service requires reconfiguration |
| Separate “free” service | Need to show zero cost directly in the list of options | Visible to everyone; filtering by amount and region requires an additional check at checkout |
| Region restrictions | Free delivery only in part of the geography | Requires correct locations in the order; for pickup the logic must be separated |
| Manual approval | Non-standard shipments, large orders | No automation: the customer waits for a response, abandoned cart rate grows |
What matters in any option
The condition must recalculate on every cart change, not only at the last checkout step — otherwise the customer sees one amount but gets another in the order.
We calculate the amount threshold based on the cost of goods excluding delivery itself, otherwise the rule will start triggering on itself.
If there are several services, we move the logic to one place: cart rules and module settings duplicate each other and diverge at the first change in tariffs.
Setup stages: from rule audit to handover of the regulation
Free delivery in 1C-Bitrix is not a single checkbox in the settings but a set of calculation rules that intersect: binding services to warehouses, customer groups, amount threshold, region, dimensions, and restrictions by payment methods.
That is why the work proceeds in stages, where each next stage relies on the result of the previous one.
- Audit of calculation rules. We export the current delivery rules, bindings of services to warehouses and customer groups, and review order history. The task is to find where conditions conflict with each other and why free delivery does not trigger with a suitable amount.
- Calculation scheme. We describe the matrix of conditions: for which regions, product types, and thresholds delivery becomes free, and for which it remains paid, including behavior on partial return.
- Choosing the mechanics. Either a separate delivery rule with zero cost or free delivery via discount — if the threshold is calculated from the entire cart and already applied promotions need to be taken into account.
- Configuration and priorities. We set the order of rule application so that the delivery discount does not stack with other promotions and does not zero out logistics margin.
- Test orders. We run scenarios: amount below the threshold, exactly at the boundary, and above; pickup; order from several warehouses; checkout by guest and authorized customer; payment on delivery.
- Handover of the regulation. We provide a rule map with priorities, instructions for editing thresholds, and a checklist for new promotions — so conditions can be changed without code edits.
Rule settings, calculation schemes, and update regulations
The client receives not a “we set it up and left” but a set of artifacts by which the work can be accepted and further changed without us. Each of them answers its own question: why free delivery triggered or not, and who has the right to bypass the rule.
- Rule configuration: binding services to warehouses, product groups, and payer types.
- Calculation scheme: order of applying discounts and rounding before threshold checking.
- Restriction policy: regions, weight, dimensions, and excluded product groups.
- Manager instructions: manual change of delivery in an order and history record.
- Threshold update regulation: who initiates revision and how the edit is verified.
- Checklist: carts at the threshold boundary, with an exclusion, with two warehouses.
Separately, we record what to recheck after which change — editing conditions should not break neighboring scenarios.
| Change | What we edit | What we check |
|---|---|---|
| New threshold | Condition in the rules | Cart at the boundary and one step below |
| New service | Binding to warehouse and zone | Calculation when it is selected |
| Time-limited promotion | Validity period of the condition | Rollback of logic after it ends |
The threshold update regulation is tied to carrier changes, not to the calendar: when tariffs are revised, conditions are checked and edited in one place — in the rule configuration, not in the checkout template.
Case study: how moving rules eliminated order calculation errors
The client is a distributor with retail and wholesale operations. Free delivery conditions lived in four places: the checkout template, the cart handler, the administrative area, and order export to 1C.
Each had its own rule, and the discrepancy produced orders with zero shipping cost that were later corrected manually.
Moving the rules
We collected all conditions into one module on the 1C-Bitrix side: it calculates shipping cost both for the customer, when recalculating an order from the administrative area, and when exporting to 1C.
The amount threshold, region, and weight are read from a reference book rather than from template code, so the condition changes without releasing a site update.
Separately, we covered the branches that were previously handled manually: pickup, partial return of items, and orders from several warehouses. Each has a test on reference carts — a new regional restriction is verified before publication.
Metrics before and after
Head of the department: “It seemed we were fixing small things until we counted how many orders went out with free shipping where it should not have been. Now the condition changes in one place, and a discrepancy with 1C surfaces at checkout, not a week later.”
What to do if shipping logic is already set by another module?
If free delivery already works — through a third-party module, a custom handler, or a template edit — the task is not to enable it again but to remove the rule conflict.
The 1C-Bitrix platform runs the cart through a chain of handlers: each recalculates delivery cost, and the result of the one that ran last is applied. While there are several handlers, behavior is unpredictable: two customers with the same cart either have delivery or do not.
We start with an inventory: which handlers are registered, where delivery profiles are overridden, what is hardcoded in the checkout template, and which conditions are set in the third-party module settings.
Then we assemble a matrix — region, weight, cart amount, customer group, delivery service. Some conditions are usually duplicated in two or three places with different thresholds, and the discrepancies produce those very strange free orders.
We move the conditions to the standard mechanism — cart rules and delivery profiles. We go service by service, and we do not delete old handlers but disable them: until the new calculation is verified, there must be a rollback path with one edit, without restoring from a backup.
Configuration migration proceeds with history preserved: delivery cost in placed orders is fixed, and switching the logic does not rewrite them.
We perform the switch in parallel: the new and old calculations compute delivery simultaneously, discrepancies go into a log — it is visible where conditions did not match.
When there are no discrepancies, we disable the third-party module, remove template edits, and clean up duplicates. After that, free delivery lives in one place: a module update, tariff change, or new region will not break it.
Common technical questions about order cost calculation
Order cost calculation in 1C-Bitrix is a place where an error is immediately visible to the customer and costs the store trust. Below are common calculation questions asked before work starts, with short answers from the engineer.
How to restrict free delivery by region?
The condition is tied to the customer's location: zones are set as a list of regions, and the amount threshold is calculated separately for each. Outside the zone, the rule does not trigger — the customer sees a paid rate and does not get a surprise at checkout.
Can different shipping conditions be set for customer groups?
Yes: cart rules work by group, and wholesale and retail customers get their own threshold. We check that the group is assigned automatically upon registration, otherwise the condition simply will not apply.
What happens if several conditions conflict?
Rules trigger by priority: on overlap, the first matching one applies, and the rest are disabled. Before launch, we run a scenario matrix — region, group, amount — so that a promotion and free delivery do not overlap.
Will the settings survive a platform update?
We move the calculation logic into a custom module and handlers, not into the checkout template. Updating the core and standard modules then does not overwrite the conditions — they live separately from standard files.
Who is responsible for calculation correctness?
We fix the calculation with a set of checks and hand over a rule map: it is visible which condition is responsible for what and in what order it triggers. The same map serves as a rollback point for future edits.
Let's discuss the task: shipping rules for your conditions
Shipping rules depend on region, order amount, shipping warehouse, and customer group — there is no universal setting here.
To avoid redoing the logic after launch, on a call we review the conditions and look at the live site: which delivery services are connected, how cost is calculated, and where the discount is currently inserted.
This is enough to come back with a work estimate and setup plan. What we clarify and which data we review:
- geography: which regions you serve and whether there are zones with special conditions;
- threshold: from what order amount delivery becomes free and how it relates to the minimum order amount;
- mechanics: a separate delivery discount, a rule with a cart restriction, or a separate service with filtering;
- customer groups: retail, wholesale, partners — who can access the rule and who cannot;
- warehouses and receiving methods: pickup, courier, pickup points, several shipping warehouses;
- access: a test environment or live site where the rules can be checked without risk to live orders.
Along with the estimate, we send a setup plan: which rules we create, in what order we enable them, how we test on test orders, and how we roll back. We discuss cooperation terms there as well.
Describe the task in two or three sentences — we will discuss it specifically and come back with an estimate and plan.