Delivery calculation on Bitrix: where the logic breaks
Delivery cost in the cart is the most common place for discrepancies in an order. The customer sees one amount, the manager in the admin panel sees another, and the carrier's invoice comes with a third.
The reason is not the design, but that the calculation is assembled from several independent sources, and none is responsible for the total as a whole.
Rate grids overlap each other: carrier rates are stored in different reference books, and the order in which conditions are applied — region, weight, order amount — is not fixed anywhere.
The rule that runs last wins; if the carrier's service does not respond, the calculation silently returns zero, and the order goes through with zero delivery cost. Typical delivery calculation errors are exactly here, not in the rates themselves.
The second source is dimensions. If only weight is filled in on the product page, the calculation goes by weight, while the carrier calculates by volumetric weight and the number of packages.
The discrepancy surfaces already in the invoice, and the manager sorts it out manually, checking the waybills against the order.
Manual order edits finish the picture.
The manager changes the delivery amount after checkout, but the saved calculation result, discounts and taxes remain from the previous amount — the total in the invoice and the waybill does not match, and the change history is not saved anywhere.
We analyze how this is closed: a unified order of applying rules with explicit priorities, mandatory checking of dimensions before calculation, and recording the result in the order with an edit history.
What changes after setup: checkout speed and invoice accuracy
Correct calculation logic removes from checkout the steps that the manager used to perform: manual price recalculation, rate confirmation by phone, and additional requests for dimensions.
The customer sees the final amount right in the cart and goes through checkout in one pass — order checkout speed increases, and the order no longer "hangs" until a call.
Rate accuracy rests on a set of reference books: weight and dimensions of the product, rate zones by index and region, binding of the shipping warehouse, free delivery thresholds by amount and weight, rounding rules, and markups for remote destinations.
If at least one reference book is partially filled, the cost is calculated "by eye" and diverges from the carrier's invoice.
A separate class of checkout failures is the message "delivery not calculated" and an empty list of options. They occur on uncovered zones, non-numeric weight, an unavailable external calculation service, or an outdated saved rate.
A fallback delivery option, a response timeout limit, and clear text instead of an empty screen close these scenarios — the customer does not leave to look for the cause themselves.
The practical effect is measured in three numbers: the share of orders that go through without manual invoice correction; the average time from cart to confirmation; and the share of failures at the delivery selection step.
In 1C-Bitrix this is done with standard delivery handlers, cart rules, and exchange with 1C — without custom add-ons that break with every platform update.
Calculation methods: zones, weight, dimensions, fixed rate
The delivery calculation method determines which data must be in the catalog before launch. A fixed delivery rate requires nothing but the rule itself, but it calculates an order to a neighboring house and to another region the same way.
Zone rates remove this limitation, but they tie the store to a location reference book and to zone slicing.
Weight-based calculation is more accurate, but it shifts responsibility to the product page: mass must be filled in for every item, including kits and sets.
If the weight property does not come from 1C during exchange, checkout either does not find a delivery method or calculates it as zero — the most common cause of failure after integration.
How the options compare
| Calculation option | When it fits | Restrictions on catalog and checkout |
|---|---|---|
| Fixed delivery rate | one city, pickup, city courier | does not distinguish regions and oversized cargo; when geography expands, the rule is rewritten |
| Zone rates | two or more regions, each with its own rate and lead time | requires an up-to-date location reference book and zone binding; a new city is a zone edit, not a code edit |
| Weight-based calculation | wide range of mass: from a document to a pallet | weight is required for every item; during exchange, the property has to be mapped, otherwise the calculation returns zero |
| Combined logic | multiple services and different rules in one cart | the order of checks is set manually, and testable scenarios are needed for each combination |
Combined logic is assembled as a sequence: first the zone is determined by location, within the zone weight or item total is calculated, dimensions act as a cutoff for oversized services, and pickup covers cases where delivery is unavailable.
The order of these checks is fixed in the cart rules, so when a new service is added, it is clear at which step it is integrated.
Work stages: from auditing conditions to testing on real orders
While delivery rules live in the manager's head and in a spreadsheet, every new rate turns into manual order edits.
We start with an audit of carrier conditions and finish by reconciling calculations with real waybills — this way the scheme is tested on completed orders, not just in words.
- Delivery conditions audit. We collect rate zones, weight and dimension restrictions, free delivery thresholds, rounding rules, and surcharges for remote areas — in the form in which the warehouse operator and accounting apply them.
- Rules scheme. We fix priorities: which rate triggers when zones overlap, what to do when the limit is exceeded, how the payment method affects it. The scheme is agreed in writing before setup begins.
- Calculation implementation. We configure order processing profiles and binding to warehouses and services so that the cost is inserted into the cart and saved in the order, rather than recalculated manually by the manager.
- Test orders. We run boundary scenarios: minimum and maximum weight, an address at the junction of zones, an undeliverable region. We record the expected result in the test table in advance.
- Reconciliation with waybills. We take completed orders and compare the calculated amount with the actual one on the waybill. We consider a discrepancy a rule error and fix it until there is zero deviation.
- Handover and training. We hand over the regulation: how to add a zone, change a threshold, update a rate. The manager handles typical edits themselves, without contacting development.
The work is considered complete when the calculation is reproduced on a repeat run of test orders and matches the waybills.
Documentation set: rate rules, zone schemes, regulations
The documentation set is what remains with the client's team after delivery calculation handover. Without it, any rate edit turns into code analysis: it is unclear where the condition is, why it triggered, and what will break when a region is added. That is why we record not only the settings but also the logic of their application.
- Delivery zone scheme — mapping of regions, cities, and address attributes to zones, including boundaries: ambiguous address, partial match, missing data.
- Conditions matrix — a table where the axes are zone, weight and dimensions, payment method, and recipient type, and the cells contain the rule and its priority when overlapping.
- Configured rate rules — a list in order of application with an explanation of which rule overrides another and where the default base rate is.
- Rate update regulation — who makes the edit, at what point, how it is checked, and in what form it goes to the production site.
- Edit instructions — typical actions: new region, new service, threshold change, disabling a condition.
- Verification procedure — control orders for each zone and a set of cases against which the result is checked after any edit.
- Change log — what, when, and at whose initiative changed, so that six months later the reason for a decision can be reconstructed.
The documentation sits next to the settings and is updated together with them: an edit without a record in the regulation is considered incomplete.
Case study: invoice and order discrepancies reduced to isolated cases
What it was before the rework
A store on 1C-Bitrix calculated delivery using one general rate: everything that did not fit it — oversized cargo, multiple warehouses, remote regions — the manager calculated manually.
About every third order went into manual price correction, checkout stretched to several minutes, and the discrepancy between invoice and order surfaced already at shipment.
Refunds caused by pricing came in a steady stream: the customer saw one amount, and the invoice came with another.
What was changed
We assembled calculation rules: delivery zones, weight and dimension ranges, warehouse markups, separate conditions for pickup and oversized cargo.
The calculation was moved to a separate layer with a log — now every amount in the order has a source and the parameters by which it was obtained.
We added a cache of delivery service responses and a fallback rate: if the external service does not respond, the order is placed using the last successful value with a note for the manager, instead of failing with an error.
Metrics before and after
The share of orders with manual price correction fell from a third to 2–3%, and checkout time — from four to five minutes to a little over a minute. Refunds caused by pricing dropped from a dozen per month to isolated cases.
The discrepancy between invoice and order is now caught by reconciliation at the checkout stage: the order amount and invoice amount are compared automatically, and the discrepancy goes to the log, not to the customer.
This delivery setup case showed the main thing — managers stopped working as calculators, and non-standard cases remained the only reason for intervention.
Setup limitations and disputable cases during checkout
Overlapping rate grids are the most common source of disputable orders. When a rule by region, weight, and amount threshold fit simultaneously, the result depends on the order of application: if summation is configured instead of priority, the customer sees double delivery cost.
We set an explicit priority of rules and record in the order which one triggered — when handling a request, it is clear where the amount came from.
Pickup and pickup points add a second layer. Part of the cart may go to a pickup point, part by courier, and oversized cargo does not pass the point's restrictions.
Therefore, the calculation is done not for the order as a whole, but by groups of items: each has its own rate and its own pickup point.
Orders from uncovered regions cannot be left on autopilot. If no rate is found, the system should not show zero delivery, but switch the order to approval mode — otherwise the problem is discovered after payment. On 1C-Bitrix this is closed with a separate stub rule and an entry in the event log.
What happens if none of the delivery calculation rules triggered?
The order is saved, the delivery cost is marked as to be clarified, the responsible manager receives a notification and contacts the customer.
Checkout does not break at the delivery selection step, and the calculation history remains in the order card — it is clear which rules were checked and why they did not fit.
Let's discuss the task: what is needed for an accurate estimate
For an accurate estimate of work, we need not a general idea, but a working picture of the calculation: where the rates come from, by what rules the cost is calculated, and what happens at checkout when the delivery service does not respond.
The more specific the input data, the fewer assumptions in the estimate and the more realistic the implementation plan. Below is what usually removes half the questions before the start.
- List of delivery services and receiving methods: courier, pickup points, self-pickup, own couriers — broken down by regions and zones.
- Tariffication rules: calculation by weight, dimensions, declared value, number of packages; markups by region and surcharges for urgency.
- Source of rates: data exchange with the delivery service, your price list, or a spreadsheet that managers maintain manually.
- How the cost is calculated now and what customers complain about: discrepancy with the actual, reset when the address changes, no options.
- Behavior when the external service is unavailable — show a fallback rate, an "on request" rate, or block checkout.
- Conditions that break the calculation: free delivery over amount, promotions, minimum order, oversized cargo.
- Accesses: test stand, admin panel, order export, contacts of the person responsible for logistics.
Send this in free form — as a list or screenshots of the current settings.
We will analyze how the calculation will fit into checkout and existing rules, after which we will return with an estimate of work and an implementation plan: stages, scope of edits, and the order of rollout to the production site. Describe the task — and we will discuss what we do first.
What to do if carrier rates have changed and the site is already configured?
A carrier rate is an external data source, not a constant in the code: the zone, weight and dimension coefficient, and surcharge for remote addresses change.
A carrier rate change is a routine event, so the question is not "update or not", but at what point the value is inserted: when the cart is rendered or at the moment of checkout.
| Reaction option | When it fits | What happens to catalog and orders |
|---|---|---|
| Edit in the calculation template | one carrier, rare changes | every change is a release deployment; some carts remain on the old figure |
| Import price list into reference book | multiple carriers, planned changes | recalculation without a release; line validation for gaps and a download log are needed |
| Online request to carrier service | rate depends on address and changes often | calculation is always up to date, but a timeout and a fallback reference book are mandatory |
| Markups and thresholds by rules | sales conditions change, not the base rate | rules are edited separately from the reference book; base values are not touched |
Two conditions most often break the calculation. Cache: if rates are cached for a long time, the cart will show one amount, and the order will be charged at another — the key is tied to zone and weight, and it is forcibly reset when the price list is loaded.
History: in a placed order, the rate is fixed and is not recalculated retroactively, otherwise the amount of an already agreed deal changes.
Delivery calculation support and rate updates on the site are a regulation, not a one-time edit: who monitors changes at the carrier, a test order after each load, a reference book version log, and rollback to the previous rate set.
Describe how the calculation is set up now — we will return with an estimate and a plan for moving to managed rates.