Удобный калькулятор доставки в пределах города для сайта СКМ-Мебель
У доставки есть неприятная особенность: она редко считается по простому правилу "город - цена".
В одном районе машина едет быстро. В другом - дальше, дольше и дороже. Где-то доставка попадает в городскую зону, где-то уже начинается пригород. А если интернет-магазин растет и подключает новые направления, старая схема быстро превращается в набор исключений.
Так было на сайте СКМ-Мебель.
На сайте использовалось много отдельных служб доставки: "Екатеринбург центр", "Екатеринбург юго-запад", "Екатеринбург уралмаш" и другие. Каждая служба отвечала за свою зону. На первый взгляд, логика понятная. Но чем больше зон, тем сложнее поддерживать цены, добавлять новые территории и объяснять пользователю, какой вариант ему выбрать.
Мы заменили эту таблицу на калькулятор доставки с картой, геозонами и автоматическим расчетом стоимости по адресу.
О клиенте
СКМ-Мебель - интернет-магазин и производственный участок для тех, кто делает мебель. В каталоге компании есть листовые материалы, столешницы, стеновые панели, мебельная и кухонная фурнитура, фасады, мойки, бытовая техника и системы хранения. Отдельно компания оказывает услуги цеха: распил, кромление, присадку, фрезеровку, резку стекла и изготовление радиусных деталей. На сайте также работают онлайн-сервисы: раскрой, конструкторы кухни, шкафов-купе, фасадов и дверей-купе.
Что нужно было изменить
Клиенту нужна была не просто карта на странице доставки.
Нужно было убрать лишнюю сложность из оформления заказа. Пользователь должен ввести адрес или выбрать точку на карте и сразу понять, сколько будет стоить доставка. Менеджер - не держать в голове десятки зон и не править вручную несколько служб доставки при каждом изменении тарифа.
Старый подход мешал сразу в нескольких местах. Пользователю приходилось разбираться в вариантах доставки. Менеджерам было неудобно поддерживать стоимость для разных зон. Новые регионы требовали создания новых служб доставки. Изменение цен занимало больше времени, чем должно.
Неудобно.
Задача звучала так: сделать единую систему расчета, которая сама определяет стоимость доставки по адресу пользователя и при этом остается управляемой для сотрудников клиента.
Почему отдельные службы доставки перестали работать
В 1С-Битрикс можно настроить несколько служб доставки и назначить каждой свои условия. Для простых случаев этого хватает. Например, если есть доставка по городу и доставка за городом.
Но у СКМ-Мебель логика была тоньше. Стоимость зависела от зоны, а зона - от конкретного адреса. Значит, стандартного выбора из списка уже мало. Пользователь может не знать, к какой зоне относится его улица. Менеджер может ошибиться при ручной проверке. А администратор сайта получает лишнюю работу при каждом обновлении тарифов.
Мы часто видим такую ситуацию в интернет-магазинах с региональной логистикой. Пока доставок мало, все кажется терпимым. Потом появляется еще один район, затем пригород, затем новый город. И система, которую когда-то быстро собрали из стандартных настроек, начинает мешать продажам.
Здесь было так же.
Что мы разработали
Мы сделали собственную службу доставки, которая рассчитывает цену не по названию зоны в списке, а по координатам адреса.
Пользователь вводит адрес вручную или выбирает точку на карте. Система получает координаты через Яндекс.Карты, проверяет, попадает ли точка в заданную polygon-зону, определяет тип зоны и возвращает стоимость доставки. Если адрес не попадает ни в одну область, сайт не пытается угадать цену. Он показывает честное сообщение: "Стоимость доставки рассчитывается менеджером".
Это важная деталь. В доставке лучше не показать цену, чем показать неверную. Ошибка в зоне доставки уже создает конфликт: клиент оформил заказ с одной суммой, а менеджер потом вынужден объяснять, почему цена изменилась.
Мы заложили безопасную логику: там, где система уверена в зоне, она считает автоматически. Там, где данных не хватает, подключается менеджер.
Как это работает для покупателя
Пользователь не видит внутреннюю механику. И не должен.
На стороне сайта все выглядит просто: выбирает доставку, указывает адрес, видит стоимость. Если нужно, может посмотреть маршрут от склада до адреса на карте. Это снижает количество уточнений до оформления заказа.
Для магазина это тоже плюс. Когда цена доставки понятна до отправки заявки, менеджер меньше времени тратит на однотипные вопросы. Покупатель не ждет ручного расчета там, где его можно сделать сразу.
Кажется, мелочь. Но именно такие мелочи часто тормозят оформление заказа.
Особенно в магазинах, где товар крупный, доставка зависит от машины, расстояния и зоны, а клиент хочет понимать итоговую стоимость до разговора с менеджером. 
Что происходит внутри системы
Внутри мы собрали отдельную логику расчета, чтобы не размазывать ее по шаблонам и стандартным компонентам.
Основной расчет вынесли в PHP-класс. Он отвечает за проверку координат, определение зоны и возврат стоимости. Для работы с картой и изменением стоимости на стороне пользователя сделали JS-класс. Также реализовали компонент для отображения зон доставки и отдельный обработчик службы доставки.
Геозоны хранятся в инфоблоке 1С-Битрикс. Каждая зона задается polygon-областью на карте и может иметь свою стоимость. В проекте использовались городские и пригородные зоны. Такая структура позволяет добавлять новые области и регионы без переписывания логики оформления заказа.
Это был один из главных технических принципов: менять данные должно быть проще, чем менять код.
Администрирование цен
Отдельно мы доработали управление стоимостью доставки.
Если бы менеджерам пришлось вручную открывать каждую зону и менять цену в административной части, часть проблемы осталась бы на месте. Поэтому стоимость доставки импортируется из Excel-файла через модуль импорта и экспорта.
Теперь цены можно поддерживать централизованно. Менеджер обновляет файл, загружает его в систему, и сайт использует новые значения. Polygon-зоны при необходимости редактируются отдельно через административную часть.
Такой подход удобен для клиента по простой причине: тарифы меняются чаще, чем география доставки. Цены можно обновлять быстро, а границы зон трогать только тогда, когда действительно меняется логистика.
Самая сложная часть - оформление заказа
Главная сложность была не в карте.
Сложность была в стандартном компоненте оформления заказа 1С-Битрикс. В нем много связанной логики, AJAX-обновлений и зависимостей между службами доставки, адресом, корзиной и итоговой стоимостью.
Нужно было аккуратно встроить собственный расчет, не нарушить обновление служб доставки и сохранить стабильное оформление заказа. Если вмешаться грубо, можно получить неприятные ошибки: цена не обновляется, служба доставки сбрасывается, оформление заказа зависает или пользователь видит старую стоимость после смены адреса.
Мы пошли другим путем. Минимизировали изменения стандартного компонента и вынесли бизнес-логику в отдельные классы. Кастомизация осталась точечной: оформление заказа обращается к нашей службе доставки, а сама логика расчета живет отдельно.
Так проще сопровождать проект. И спокойнее обновлять.
Интеграция с картой
Яндекс.Карты в этом проекте использовались не как декоративный блок.
Карта стала частью расчета. Она принимает адрес, помогает получить координаты, показывает зоны доставки, позволяет выбрать точку вручную и строит маршрут от склада до адреса.
Отдельное внимание потребовалось двум сценариям. Первый - пользователь вводит адрес руками. Второй - пользователь выбирает точку на карте. Оба сценария должны приводить к одному результату: система получает координаты, проверяет polygon-зону и возвращает корректную стоимость.
К нашему разочарованию, такие сценарии редко работают хорошо "из коробки". Адрес может быть введен неполно. Геокодер может предложить несколько вариантов. Пользователь может поставить точку рядом с нужным домом, но уже за границей зоны. Поэтому расчет должен быть устойчивым к таким ситуациям и не обещать цену там, где система не может ее подтвердить.
Что получилось
Мы заменили набор отдельных вариантов доставки единой системой расчета.
На сайте появился автоматический расчет доставки по адресу. Пользователь может ввести адрес или выбрать точку на карте, увидеть стоимость и маршрут. Если адрес выходит за заданные зоны, сайт передает расчет менеджеру.
Для сотрудников клиента упростилось администрирование. Вместо ручного редактирования множества служб доставки появилась централизованная работа с ценами через Excel-импорт. Зоны доставки остались управляемыми через административную часть.
Для развития сайта это тоже важно. Новые регионы и зоны можно добавлять в существующую модель, не собирая каждый раз новую схему служб доставки. Логика оформления заказа при этом остается той же.
Что в этом проекте главное
В этом кейсе ценность не в том, что на сайте появилась карта.
Карта сама по себе ничего не решает. Она полезна только тогда, когда связана с расчетом, оформлением заказа и администрированием тарифов.
Мы сделали кастомную доставку так, чтобы она работала сразу на трех уровнях: покупателю проще оформить заказ, менеджеру проще поддерживать цены, сайту проще расти на новые зоны и регионы.
Для интернет-магазина это хороший результат. Клиент быстрее понимает условия доставки. Сотрудники меньше зависят от ручных проверок. А система перестает быть набором отдельных служб, которые нужно постоянно держать в порядке вручную.