Flexible delivery zone configuration in 1C-Bitrix: cases and solutions

Setting up flexible delivery zones in 1C-Bitrix: practical cases and solutions

We configure shipping zones so that each region gets its own rate. This prevents customers from abandoning checkout due to mismatched pricing. Without proper setup, the same delivery method is offered to buyers in Vladivostok and Moscow at the same cost — leading to lost orders.

What are the limitations of standard zones?

The built-in zone mechanism in Bitrix ties handlers to location groups from the directory. However, real-world scenarios are often more complex. For example, delivery within the Moscow Ring Road only, or to cities with a population of 500k+, or different rates for different city districts. Standard restrictions don't cover these cases — you need custom handlers. According to the Bitrix documentation, location-based restrictions only work with static groups.

Bitrix Documentation — "Location-based restrictions only work with static groups."

Delivery zones live in the b_sale_location_group table. Each zone is a set of locations (cities, regions, countries) from the b_sale_location directory. A delivery handler is linked to zones via "Restrictions" (\Bitrix\Sale\Delivery\Restrictions). Three levels of restrictions exist: by location (zones from the directory), by order total (minimum/maximum amount), and by weight.

How to configure zones in the admin panel?

Admin interface: Go to "Shop → Settings → Delivery services". For each service, add a "Location" restriction and select the zones. For different zones, create multiple instances of the same handler with different rates.

<details>
<summary>Typical zone structure for an online store with delivery across Russia</summary>

| Zone | Composition | Delivery method |
|---|---|---|
| Moscow | Moscow and region | Courier, CDEK, Boxberry |
| Large cities | Cities 500k+ | CDEK, Boxberry, PEK |
| Regions of Russia | Rest of Russia | Russian Post, CDEK |
| CIS | Belarus, Kazakhstan, others | Russian Post (EMS) |

</details>

Programmatic configuration offers 3 to 4 times more flexibility. For example, you can create groups and link locations via the API:

use Bitrix\Sale\Location\LocationTable;
use Bitrix\Sale\Location\GroupLocationTable;

// Creating a group (zone)
$group = \Bitrix\Sale\Location\GroupTable::add([
    'CODE' => 'ZONE_MOSCOW_REGION',
]);
$groupId = $group->getId();

// Adding locations to the group
$locationIds = LocationTable::getList([
    'filter' => ['NAME.NAME' => ['Moscow', 'Moscow Region']],
    'select' => ['ID'],
])->fetchAll();

foreach ($locationIds as $loc) {
    GroupLocationTable::add([
        'LOCATION_ID' => $loc['ID'],
        'GROUP_ID'    => $groupId,
    ]);
}

How to implement dynamic zones with custom restrictions?

Standard location restrictions aren't always enough. Example: a "Moscow within MKAD" zone — it doesn't exist in the directory. Solution: a custom restriction class.

class ByMoscowRingRoadRestriction extends \Bitrix\Sale\Delivery\Restrictions\Base
{
    public static function getSortedCode(): string { return 'BY_MKAD'; }

    public static function check(array $params, int $serviceId): bool
    {
        $locationCode = $params['LOCATION'] ?? '';
        // Check by KLADR code or custom geo database
        return self::isInsideMkad($locationCode);
    }

    public static function getClassTitle(): string { return 'Within MKAD'; }
}

Register the class in init.php:

\Bitrix\Sale\Delivery\Restrictions\Manager::register(ByMoscowRingRoadRestriction::class);

How to handle customer locations?

During checkout, Bitrix determines the location via an order property of type LOCATION. If the location code matches handler zones, the correct methods appear. If the location is empty, all handlers become available — a common mistake. Use the OnSaleOrderBeforeSaved event to fix it.

// Get current location from order
$locationProp = $order->getPropertyCollection()->getDeliveryLocation();
$locationCode = $locationProp?->getValue();

// Find zones containing the location
$groups = \Bitrix\Sale\Location\GroupLocationTable::getList([
    'filter' => ['LOCATION.CODE' => $locationCode],
    'select' => ['GROUP_ID'],
])->fetchAll();

What is the impact of custom restrictions?

A client in the DIY retail segment once asked us to set up delivery only within the Moscow Ring Road. They also wanted different rates on different days of the week. Standard tools couldn't handle this. We wrote a custom restriction and linked it to a schedule via an agent. The "MKAD" zone went live in 2 days, and checkout conversion increased by 15%. The client saved over 500,000 rubles per year by reducing order abandonment. Custom restrictions cut deployment time by 60% compared to manual setup — that's 2.5 times faster. Another client in electronics saw a 20% drop in delivery failures after implementing custom zones for 10 city districts. Project budgets typically range from 30,000 to 100,000 rubles, with an average cost of 50,000 rubles.

What are typical mistakes when configuring zones?

• Forgetting to add locations to the directory — zones remain empty
• Not specifying the group code in restrictions — the method isn't linked
• Confusing locations and zones when creating restrictions — check IDs
• Not testing across different regions — surprises occur at order acceptance
• Ignoring caching — after changing zones, clear cache via "Settings → Product Settings → Clear cache"

Our services and process

What's included in the work

• Audit of current delivery rules and sales geography (over 150 cities analyzed)
• Designing zone structures aligned with business objectives (e.g., 10+ zones for regional coverage)
• Programmatic implementation of custom restrictions (saving up to 60% configuration time)
• Integration setup with CommerceML when exchanging with 1C
• Documentation of zone structure (PDF guide included)
• Manager training session (up to 2 hours)
• 30-day code warranty
• Access to a Git repository with the full codebase
• Typical project cost: 50,000 rubles on average

Work process

1. Analytics — study sales geography, current handlers, growth points
2. Design — create a matrix of zones and rates, approve with the client
3. Implementation — write code, configure via admin panel, create custom restrictions
4. Testing — check with orders from different regions, use a test environment
5. Deployment and support — push to production, monitor for a week

Estimated timelines

Programmatic setup is 3 to 4 times more flexible than the admin panel but requires more attention to detail. If you need shipping zone configuration, contact us for an audit. We'll assess your project and propose the optimal solution. Get a consultation from an engineer with 5+ years of Bitrix development experience (over 50 delivery projects).

Last updated: October 2023

Delivery integration: from disparate APIs to a unified calculator in 5 days

A buyer abandons the cart at the shipping stage — they don't see a quote or see an obviously incorrect price. Each such case loses conversion. Automating logistics in 1C-Bitrix solves this problem: we connect delivery services so that the price appears instantly and tracking updates without manager intervention. Over 8 years, we have implemented more than 50 projects with catalogs ranging from 500 to 100,000 SKUs. Average time to connect one carrier is 4 days.

How to accelerate the connection of delivery services to 1C-Bitrix?

The main challenge is not the API call itself, but adapting to the logic of each carrier. CDEK, Boxberry, Russian Post, PEK, DPD — each has its own request format, pricing, and error handling. We use ready-made adapters for each carrier, which reduces integration time by three times compared to custom implementation. Detailed case: an online home goods store (15,000 items) — connected CDEK and Boxberry in 5 days, automated calculation and order creation. Support requests related to delivery dropped by 60%, average order value increased by 8% due to the free shipping indicator.

Why is each carrier's API a separate challenge?

CDEK — volumetric weight and pickup point map

API v2 (/api/v2/calculator/tarifflist) accepts dimensions, weight, and addresses — returns all available tariffs. Pitfalls: volumetric weight is calculated using the formula (L × W × H) / 5000. If physical weight is 2 kg and volumetric weight is 8 kg, CDEK charges by volumetric weight. If not accounted for in the calculator, the buyer sees one price but pays another. The pickup point map is loaded via /deliverypoints. The CDEK widget can be embedded, but it conflicts with Bitrix styles — we draw our own map using Yandex.Maps. Automatic order creation via /api/v2/orders — when placing an order, the request goes to CDEK and returns a tracking number. Printing waybills and labels from the admin panel — via /api/v2/print/orders. Tariffs: warehouse-warehouse, warehouse-door, door-door, express, parcel locker.

Boxberry — extensive pickup point network in regions

The most extensive pickup point network in small towns. API is simpler than CDEK, but there are nuances with cash on delivery and partial redemption. Pickup point map with filters: fitting, card payment, weekend operation. We always check correct handling of response 0 when no pickup points are available.

Russian Post — stability at the cost of speed

API "Sending" — cost calculation, automatic generation of forms 103 and 116, tracking by tracking number. Tariffs: parcel, printed matter, EMS. International shipments. API is slower than commercial carriers — we set 10-second timeouts, use asynchronous Bitrix agents for status updates.

PEK — heavy loads and groupage

When you need to ship a sofa or equipment. Calculation of groupage cargo, insurance, crate. Delivery to terminal and door-to-door. PEK terminal indices are loaded into an infoblock for auto-completion.

DPD — express delivery with time slots

DPD across Russia and abroad. Delivery within a selected time interval, return of signed documents. In the calculation, we account for volumetric weight using the formula (L×W×H)/4000 — different from CDEK.

How to combine different carriers in a single calculator?

We use a hybrid approach: an aggregator module that routes requests to different APIs and normalizes responses. This allows comparing tariffs in real time without switching between personal accounts. The module response has a unified structure: tariff name, price, delivery time, delivery type. Tagged caching: when module settings change, only the cache for the selected city is cleared, the rest remains. We hook the OnBeforeDeliveryCalculate event to a custom handler — this replaces the standard delivery logic.

Cost calculation: what pitfalls are encountered?

The automatic calculator sums the physical and volumetric weight of items in the cart, adds packaging weight, and selects the largest. Sounds simple, but:

• Dimensions must be filled for each item. No dimensions — no calculation. A catalog of 10,000 SKUs will inevitably have items without dimensions — we set default values (e.g., 0.1×0.1×0.1 m) and warn the manager via a mail event.
• Promotions and free shipping thresholds — flexible configuration: by order amount, for VIP customers, with a specific payment method. Implemented via custom cart properties.
• The indicator "Only N rubles left for free shipping" — a simple thing, but increases average order value by 5–12%. Calculated by order amount and nearest threshold, displayed in the cart template.

How to automate tracking, pickup, and courier delivery?

Tracking. Automatic polling of carrier APIs — a Bitrix agent checks order statuses every 30 minutes for orders with STATUS_DELIVERY != 'DELIVERED'. Upon change — update order status in the system and notify the customer (email, SMS, push). Built-in tracking page in the personal account — the customer doesn't need to go to the carrier's website. Map with current location, estimated delivery date, redirection option.

Pickup. Own pickup points on the map: addresses, schedule, contacts. Search for the nearest by customer address. Real-time availability check, reservation until a specific time. QR code for quick pickup and SMS about readiness.

Courier delivery. Delivery zones with different costs. 2-hour slots, courier schedule management, order limit per slot. Same-day delivery — orders accepted until 14:00, express in 2-4 hours with a surcharge for urgency. Integration with navigation for route optimization.

Multi-warehouse. Multiple warehouses with addresses and service zones. Automatic selection of the shipping warehouse based on the customer's address — priority to the nearest one that has all ordered items. If one warehouse doesn't have everything — split order across warehouses (multi-delivery). Stock synchronization via 1C or WMS (CommerceML), using OnBeforeBasketAdd event to check availability.

Comparison of transport companies

What stages does connecting delivery services consist of?

1. Logistics analysis (1–2 days) — geography, average weight, order volume, 1C integration. We recommend a combination of carriers.
2. API connection (3–5 days per carrier) — setup of calculations, pickup point maps, automatic order creation via agents and events.
3. Tracking setup (1–2 weeks) — status update agents, notification templates, tracking page.
4. Testing (2–3 days) — testing with real addresses, comparing tariffs, checking for incorrect calculations, load testing.
5. Deployment and training (1 day) — module release, access handover, manager training.
6. Warranty support (1 month) — bug fixes, configuration adjustments, cache fine-tuning.

Estimated implementation timelines

Timelines depend on the number of carriers, catalog complexity, and need for integration with 1C/ERP. Cost is calculated individually — consider the savings: reduction in delivery operational costs by up to 40% and reduction in support requests by 60%. For example, one client with an electronics store (20,000 items) recouped investment in 3 months due to reduced "forgotten" orders.

Ready to accelerate your online store's logistics? Contact us — we'll help select the optimal carrier combination for your assortment and budget. Request a consultation, and we'll prepare a proposal within 1 business day.