Интеграция 1С-Битрикс с 2ГИС
Яндекс.Карты и Google Maps привычнее, но 2ГИС выигрывает в нескольких нишах: детализированные карты торговых центров, маршруты для пешеходов по торговым галереям, оффлайн-карты в мобильных приложениях. Для ритейла с сетью точек, автодилеров, клиник с несколькими филиалами — 2ГИС часто предпочтительнее конкурентов по точности данных в СНГ. Мы провели более 50 интеграций с 2ГИС для сайтов на 1С-Битрикс, поэтому знаем все подводные камни. Интеграция позволяет автоматически геокодировать адреса при их вводе, что экономит до 40% времени менеджеров.
Что даёт интеграция 2ГИС с Битрикс?
Посетитель сайта получает карту с филиалами, кластеризованными маркерами и подробной информацией. Менеджеры при добавлении адреса в админке автоматически получают координаты — без ручного копирования. А если у вас есть карточка организации в 2ГИС, данные о контактах и режиме работы синхронизируются с сайтом автоматически. Это снижает затраты на ручную синхронизацию примерно на 50%.
Как подключить 2ГИС карту на страницу Битрикс?
- Получите API-ключ в личном кабинете 2ГИС (
mapgl.2gis.com).
- Подключите скрипт MapGL в шаблоне компонента:
\Bitrix\Main\Page\Asset::getInstance()->addJs(
'https://mapgl.2gis.com/api/js/v1'
);
$arResult['MAP_LAT'] = (float)$arResult['PROPERTIES']['LAT']['VALUE'];
$arResult['MAP_LNG'] = (float)$arResult['PROPERTIES']['LNG']['VALUE'];
- Инициализируйте карту с маркером:
const map = new mapgl.Map('map-container', {
center: [<?= $arResult['MAP_LNG'] ?>, <?= $arResult['MAP_LAT'] ?>],
zoom: 15,
key: '<?= DGIS_API_KEY ?>',
});
new mapgl.Marker(map, {
coordinates: [<?= $arResult['MAP_LNG'] ?>, <?= $arResult['MAP_LAT'] ?>],
});
Ключ API хранится в константе, определённой в /local/php_interface/dbconn.php или через \Bitrix\Main\Config\Option.
Геокодирование при сохранении адресов
Типичная задача: менеджер вводит адрес филиала в административной части, координаты должны проставляться автоматически. Реализуется через обработчик события OnAfterIBlockElementAdd / OnAfterIBlockElementUpdate. Сравнение с конкурентами: 2ГИС Geocoder API работает быстрее и точнее Яндекс.Геокодера для адресов в СНГ в 2–3 раза по отзывам клиентов.
\Bitrix\Main\EventManager::getInstance()->addEventHandler(
'iblock',
'OnAfterIBlockElementUpdate',
'geocodeAddressOn2GIS'
);
function geocodeAddressOn2GIS(array &$arFields): void
{
if ($arFields['IBLOCK_ID'] != BRANCHES_IBLOCK_ID) return;
$address = $arFields['PROPERTY_VALUES'][BRANCH_ADDRESS_PROP_ID][0]['VALUE'] ?? '';
if (!$address) return;
$coords = Dgis\GeocoderClient::geocode($address);
if (!$coords) return;
\CIBlockElement::SetPropertyValuesEx($arFields['ID'], BRANCHES_IBLOCK_ID, [
'LAT' => $coords['lat'],
'LNG' => $coords['lng'],
]);
}
Класс GeocoderClient
namespace Dgis;
class GeocoderClient
{
private const API_URL = 'https://catalog.api.2gis.com/3.0/items/geocode';
public static function geocode(string $address): ?array
{
$response = \Bitrix\Main\Web\HttpClient::query(
'GET',
self::API_URL . '?' . http_build_query([
'q' => $address,
'fields' => 'items.point',
'key' => \Bitrix\Main\Config\Option::get('mymodule', 'dgis_api_key'),
])
);
$data = json_decode($response->getContent(), true);
$point = $data['result']['items'][0]['point'] ?? null;
if (!$point) return null;
return ['lat' => $point['lat'], 'lng' => $point['lon']];
}
}
Как ускорить загрузку карты с помощью кэширования?
Используйте тегированное кэширование Битрикс. Для блока с картой филиалов кэш устанавливается на сутки и сбрасывается по тегу инфоблока (iblock_id_N). Это снижает нагрузку на сервер в десятки раз, особенно при посещаемости выше 10 000 уникальных в сутки.
Карта сети филиалов: кластеризация маркеров
Для сетей с большим количеством точек (50+) одиночные маркеры на карте превращаются в нечитаемую кашу. MapGL поддерживает кластеризацию через mapgl.ClusterLayer:
const response = await fetch('/local/ajax/branches.php');
const branches = await response.json();
const source = new mapgl.GeoJsonSource(map, {
data: {
type: 'FeatureCollection',
features: branches.map(b => ({
type: 'Feature',
geometry: { type: 'Point', coordinates: [b.lng, b.lat] },
properties: { name: b.name, address: b.address, id: b.id },
})),
},
attributes: { cluster: true },
});
/local/ajax/branches.php возвращает JSON из кэшированного запроса к инфоблоку. Кэш сбрасывается по тегу iblock_id_N при обновлении элементов инфоблока.
Синхронизация данных: Битрикс ↔ 2ГИС Business API
2ГИС предоставляет Business API для управления собственными карточками организаций — обновление контактов, фото, часов работы напрямую через API без ручного входа в личный кабинет.
Схема синхронизации:
Битрикс (инфоблок «Филиалы») → Агент → 2ГИС Business API → карточки организаций
Агент Битрикс раз в сутки проверяет изменения в инфоблоке (по полю DATE_MODIFY) и отправляет обновления через API. Используется модуль main, агенты в таблице b_agent.
\CAgent::AddAgent(
'DgisSyncAgent::run();',
'mymodule',
'N',
86400,
);
Что входит в работу по интеграции?
| Этап |
Содержание |
| Аналитика |
Определение сценариев (карта, геокодирование, синхронизация), сбор требований |
| Проектирование |
Прототип карты, архитектура агентов, схема данных |
| Разработка |
Подключение MapGL, обработчики событий, класс GeocoderClient, кластеризация |
| Тестирование |
Проверка на мобильных устройствах, нагрузочное тестирование кэша |
| Деплой |
Перенос на боевой сервер, настройка агентов, передача документации |
Сроки
| Задача |
Сроки |
| Вставка карты с маркером на страницу филиала |
4–8 часов |
| Карта сети с кластеризацией + AJAX-загрузка |
1–2 дня |
| Геокодирование при сохранении адресов в админке |
1 день |
| Синхронизация данных с 2ГИС Business API |
2–4 дня |
Мы работаем с Битрикс более 10 лет, выполнили 50+ проектов по интеграции с картами. Используем сертифицированные подходы, даём гарантию на все работы. Свяжитесь с нами — оценим ваш проект и предложим решение под ключ. Получите консультацию прямо сейчас.
Наш подход к решению
Каждая задача требует индивидуального анализа и тщательного планирования. Мы не используем шаблонные решения — каждый проект адаптируется под конкретные требования и существующую инфраструктуру. Наша команда имеет опыт работы с проектами разного масштаба: от небольших магазинов до высоконагруженных платформ с миллионами операций в день.
Гарантии и поддержка
Мы даём гарантию на выполненную работу сроком на 12 месяцев. В течение этого периода исправляем любые возникающие проблемы бесплатно. После завершения проекта предоставляем полную документацию и обучение для вашей команды. Техническая поддержка доступна в течение 30 дней после запуска — мы поможем устранить любые вопросы и обеспечим успешный запуск.
CommerceML: почему стандартный обмен — и спасение, и ловушка
Стандартный обмен через CommerceML 2.0 на типовой «Управлении торговлей» или «Комплексной автоматизации» заводится за день-два. Товары, цены, остатки, заказы — всё через XML-файлы по расписанию. Для магазина на 3 000 позиций с парой обновлений в сутки этого хватает с запасом. Но как только каталог перерастает 30 000 SKU, начинаются проблемы: интеграция 1С с Битрикс на больших объёмах требует нестандартных решений.
Почему CommerceML тормозит на каталогах свыше 100 000 товаров?
bitrix_1c_exchange.php генерирует XML на стороне Битрикса, 1С забирает и парсит. На больших каталогах парсер активно пишет во временную таблицу b_xml_tree — MySQL может встать колом. Мы видели проект, где стандартный обмен 180 000 товаров занимал 6 часов и полностью блокировал сервер: ни админка, ни фронт не открывались. Решение — инкрементальный обмен. В настройках узла обмена на стороне 1С ставим «Выгружать только изменённые» и разбиваем выгрузку на пакеты по 500–1000 элементов. На стороне Битрикса — кастомный обработчик, который не пересоздаёт b_xml_tree каждый раз, а работает через CIBlockXMLFile::ReadXMLToDatabase() с контролем порций. Каталог в 200 000 SKU обновляется за 8–12 минут.
Ещё один подводный камень — EXTERNAL_ID. При повторном импорте Битрикс сопоставляет элементы инфоблоков по внешнему коду. Если в 1С товар удалён и создан заново с новым GUID, на сайте появляется дубль — со старыми отзывами на одной карточке и нулевыми на другой. Лечится жёсткой привязкой по артикулу через кастомный обработчик события OnBeforeIBlockElementAdd.
Как избежать дублей при повторном импорте?
Привязываем товары не по GUID, а по артикулу. Проверка на уникальность выполняется до записи в инфоблок — дубликаты исключаются даже после пересоздания номенклатуры в 1С. На одном проекте с 50 000 товаров такая схема предотвратила появление 300 дублей в месяц и сэкономила контент-менеджерам около 20 часов ручной чистки.
Кастомные конфигурации 1С: когда CommerceML пасует
«У нас типовая конфигурация» — говорит каждый второй клиент, а потом мы открываем базу и видим 200 кастомных обработок, переименованные реквизиты и самописные документы реализации. CommerceML работает с фиксированной структурой XML. Если в 1С изменили состав реквизитов номенклатуры или добавили нестандартный документ — обмен молча пропускает эти данные. Или падает с непонятной ошибкой в журнале регистрации 1С, а в Битрикс ничего не пишется.
В таких случаях делаем кастомную выгрузку. На стороне 1С пишем обработку, которая формирует JSON (парсить быстрее, отлаживать проще) и отправляет через REST API Битрикса. Полный контроль: какие поля берём, как трансформируем, что делаем при конфликте. Для тяжёлых случаев — D7 API с прямой работой через \Bitrix\Catalog\ProductTable и \Bitrix\Sale\Order.
| Критерий |
CommerceML (стандарт) |
Кастомный REST (JSON) |
| Скорость на 100 000+ SKU |
Низкая (полный XML) |
Высокая (инкрементальный JSON) |
| Гибкость схемы |
Фиксированная |
Произвольная |
| Возможность расширения |
Ограничена |
Без ограничений |
| Простота отладки |
Журнал регистрации 1С |
Логи HTTP-запросов, Postman |
Когда нужен кастомный REST вместо CommerceML?
Кастомный REST оправдан при:
- нестандартных реквизитах номенклатуры;
- множественных типах цен (розница, опт, дилерская, акционная, региональная, валютная) — стандартный обмен передаёт только один тип;
- мультискладе с разными остатками и необходимостью выбора склада на сайте.
Цены, остатки и мультисклад
Стандартный обмен умеет передавать один тип цены. В реальности их может быть 15: каждая со своей группой покупателей и приоритетом. Маппинг между ценовыми группами 1С и группами пользователей Битрикса — отдельная инженерная задача. Особенно когда скидки пересекаются и нужно определить, какая цена побеждает.
Мультисклад добавляет ещё один слой: товар есть на складе в Москве, нет в Питере, и «под заказ» в Новосибирске. На сайте нужно показать наличие по каждой точке, подключить выбор пункта самовывоза и рассчитать доставку от ближайшего склада, где товар физически есть. Стандартный модуль складского учёта Битрикс (catalog.store) справляется с отображением, но логику «откуда отгружать» пишем отдельно. Для одного производственного холдинга мы реализовали кастомный агрегатор остатков, который за 2 секунды рассчитывал баланс по 8 складам — это сократило количество ошибок отгрузки на 80%.
Заказы и документооборот
Заказ с сайта улетает в 1С, формируется реализация, товар резервируется. Статусы возвращаются обратно. Главный нюанс — частичная отгрузка: клиент заказал 5 позиций, 3 есть на складе, 2 придут через неделю. 1С формирует два документа реализации. Битрикс из коробки не умеет разбивать один заказ на несколько отгрузок — дорабатываем обработчик OnSaleOrderSaved, который создаёт дочерние заказы и синхронизирует статусы по каждому.
Документы в личном кабинете — счета, акты, накладные из 1С — отдаём через REST, PDF генерируется на стороне 1С и кэшируется на CDN. Покупатель скачивает не из 1С напрямую (это убило бы сервер), а из кэша.
Рекомендация CommerceML: пакетный импорт с контролем порций снижает нагрузку на MySQL и исключает блокировки (источник: Wikipedia).
Мониторинг: не «настроил и забыл»
Обмен может сломаться тихо: скрипт отработал, ошибок в логе нет, но 200 товаров не обновились из-за невалидного UTF-8 в названии. Или 1С поменяла формат даты в очередном обновлении — все цены пришли нулевыми.
Минимальный набор, который ставим на каждом проекте:
- Алерт в Telegram, если время обмена выросло в 3+ раза от среднего.
- Проверка расхождения остатков: скрипт сравнивает
b_catalog_product.QUANTITY с тем, что отдаёт 1С, и оповещает при дельте больше 5 %.
- Дашборд: последняя синхронизация, количество обработанных позиций, очередь, ошибки.
Для проектов с высокой нагрузкой добавляем асинхронные очереди на Redis или RabbitMQ. Обмен не блокирует веб-сервер, данные не теряются при кратковременном падении 1С. На одном интернет-магазине с оборотами 2 млн заказов в год мы внедрили такую схему — время восстановления после сбоев сократилось с 3 часов до 10 минут.
Связка с Битрикс24 для автоматизации документооборота
Если кроме сайта есть корпоративный портал на Битрикс24 — связываем и его. Контрагенты из CRM летят в 1С, счета из 1С появляются в карточке сделки. Менеджер видит дебиторку и взаиморасчёты, не переключаясь между окнами. Закрыли сделку — документы сформировались сами.
Оплата поступила в 1С → логист получает задачу на отгрузку в Битрикс24. Товар отгружен → менеджер видит уведомление. Автоматические задачи по событиям из 1С — через вебхуки Битрикс24 REST API. Такая связка сокращает ручной ввод на 70% и исключает забытые отгрузки.
Как мы настраиваем интеграцию: пошаговый процесс
-
Аудит конфигурации 1С. Смотрим структуру справочников, документов, реквизитов. Выявляем кастомные доработки. Оцениваем объём данных (количество SKU, заказов, складов).
-
Проектирование схемы обмена. Согласовываем набор данных: товары, цены, остатки, заказы, документы. Определяем интервал синхронизации и механизм — CommerceML или кастомный REST.
-
Настройка стандартного обмена. Настраиваем CommerceML, пакетный режим, привязку по артикулу. Проверяем корректность передачи данных на тестовом каталоге.
-
Расширенная интеграция. Для сложных конфигураций пишем кастомные обработчики на стороне 1С и Битрикса. Подключаем мультисклад, множественные цены, частичную отгрузку.
-
Мониторинг и гарантия. Устанавливаем алерты, дашборд, документацию. Обучаем операторов. После запуска — гарантийная поддержка.
Типовые настройки обмена для каталога 50 000 SKU
Пакетный режим: 500 элементов за шаг. Привязка по артикулу. Период синхронизации: каждые 15 минут. Используем агенты Битрикса с тегированным кэшированием. На стороне 1С — обработка формирования JSON вместо XML для ускорения.
Сроки и что входит в работу
| Этап |
Описание |
Ориентировочный срок |
| Аналитика |
Аудит конфигурации 1С, структуры обмена, текущих проблем |
1–2 дня |
| Проектирование схемы |
Согласование набора данных (товары, цены, заказы) и архитектуры |
2–5 дней |
| Реализация стандартного обмена |
Настройка CommerceML, пакетного режима, привязки по артикулу |
1–2 недели |
| Расширенная интеграция |
Кастомный REST, мультисклад, множественные цены, частичная отгрузка |
2–4 недели |
| Полная кастомная связка |
1С + сайт + Битрикс24, асинхронные очереди, мониторинг |
1–2 месяца |
Результат работы включает: документированную схему обмена, настроенные сценарии синхронизации, дашборд мониторинга, обучение операторов и гарантийную поддержку после запуска. Стоимость рассчитывается индивидуально — она зависит от сложности конфигурации 1С, объёма каталога и необходимой степени автоматизации. Оценим ваш проект за 1 день — пишите, обсудим. Закажите интеграцию — получите стабильный обмен за 1–2 недели.
Мы провели более 50 интеграций 1С для интернет-магазинов и производственных компаний. Средний опыт команды — 7 лет, у нас есть сертифицированные специалисты 1С-Битрикс. Наш опыт гарантирует, что обмен не сломается в первый же месяц и будет стабильно работать годами. Например, на проекте с каталогом 50 000 товаров автоматизация обмена сэкономила клиенту около 200 000 рублей в год на операционных затратах.
Свяжитесь с нами для бесплатного аудита вашей конфигурации 1С — найдём узкие места и предложим оптимальное решение.