Інтеграція 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С — знайдемо вузькі місця та запропонуємо оптимальне рішення.