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