Інтеграція Битрикс24 із сайтом: де розходяться дані
Типова картина: сайт на 1С-Битрикс приймає замовлення і показує вітрину, а портал Битрикс24 веде угоди, рахунки та клієнтські картки. Поки інтеграції Битрикс24 із сайтом немає, кожен контур живе своїм життям, і розходження даних сайту та порталу починається з першої ж операції.
Замовлення з сайту заводять у CRM вручну, рахунок виставляють удруге, оплату позначають окремо — це подвійне введення замовлень, яке з'їдає час менеджера і породжує дублі клієнтів.
Розрив між сайтом і CRM помічають не відразу. Менеджер змінює ціну або умову доставки в угоді, а на вітрині залишається попередня сума: клієнт оформлює замовлення за однією ціною, а рахунок отримує за іншою.
Клієнтська картка при цьому дробиться — частина історії осідає в коментарях до замовлення, частина в листуванні порталу, і повторне звернення починається з нуля.
Залишки не збігаються найчастіше. Склад списує товар у момент відвантаження, сайт — у момент оформлення замовлення, а портал — коли менеджер позначив резерв вручну.
Позиція, якої фізично вже немає, продовжує продаватися, а після скасування замовлення резерв не повертається на вітрину.
Ціна помилки зростає разом з обсягом: чим більше замовлень на день, тим ширше розходження і тим дорожче ручне звіряння, вища частка скасувань і повернень, довше збирання замовлення. Далі розбираємо, як цей розрив закривається обміном між системами.
Що дає зв'язаний контур: єдині дані та менше ручної роботи
Коли сайт і портал дивляться в одну базу, каталог ведеться один раз: картка товару, властивості, ціни та залишки розкладаються за своїми розділами без повторного введення.
Обмін будується на зовнішньому ключі номенклатури — позиція залишається тим самим записом, а не заводиться заново під час кожного сеансу, тому єдиний каталог товарів не розповзається на копії і не потребує ручного звіряння.
Замовлення більше не дублюються. Заявка з сайту потрапляє в портал один раз: ключ замовлення та повторна обробка не створюють другий документ, тому клас помилок «дубльований документ» і подвійний клієнт іде з процесу.
Швидкість обробки заявки зростає за рахунок того, що менеджер не звіряє дві бази очима, а працює з одним станом замовлення.
Автоматичне оновлення залишків іде порціями за змінами, а не повним вивантаженням — обмін завершується швидше, черга не зростає, а ціна та наявність на сайті збігаються з обліковими.
Журнал обміну фіксує кожен крок, тому розходження видно на конкретній позиції, а не спливає в момент відвантаження.
Підсумок щодо ручних операцій: введення даних зміщується до контролю винятків — спірних позицій і розходжень.
Наша команда налаштовує такий контур на зв'язці Битрикс24, сайту та облікової системи, а відповідальність за склад даних і правила зіставлення фіксуємо в регламенті обміну, щоб результат не залежав від конкретного виконавця.
Способи зв'язку сайту та порталу: обмін, шина, ручне перенесення
Режим інтеграції сайту та Битрикс24 обирають не зручністю розробника, а за двома питаннями: наскільки дані можуть відставати від реальності і що станеться, якщо одна із систем недоступна. Нижче — варіанти, між якими реально обирають на проєкті.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Обмін за розкладом | Довідники, ціни, номенклатура; затримка в години допустима | Дані відстають; конфлікти правок розв'язуються за часом зміни |
| Подієвий обмін | Замовлення, оплати, статуси — потрібна реакція за хвилини | Залежить від доступності обох систем; потрібні черга та повторні спроби |
| Проміжна база як буфер | Системи працюють у різному темпі й не перетинаються за часом | Ще один контур: супровід, моніторинг, чищення |
| Ручне перенесення | Разові міграції, звіряння, рідкісні довідники | Не масштабується, повторюваність і простежуваність низькі |
Вузьке місце зазвичай не в каналі передавання, а в моделі даних: різні ключі довідників, дублі контрагентів, незбіжні правила округлення та оподаткування. Тому до вибору режиму ми узгоджуємо ключі зіставлення, правила розв'язання конфліктів і те, яка система володіє записом.
На практиці схема гібридна: довідники — за розкладом, документи та статуси замовлень — подієво, а проміжна база закриває вікна, коли портал або облікова система недоступні. Затримка задається окремо для кожного типу даних, а не однією середньою цифрою.
Порядок робіт: від розбору даних до передачі в підтримку
Інтеграція з 1С майже ніколи не починається з чистого аркуша: на сайті та порталі вже вивантажуються прайси, залишки, замовлення, контрагенти.
Перш ніж щось змінювати, розбираємо, які об'єкти і в який бік ходять, хто власник даних і де співробітники правлять їх вручну — інакше ми просто перенесемо старі помилки в нову схему.
- Аудит інтеграції. Складаємо карту зв'язків: що синхронізується, за яким розкладом, у який бік, які правки обходять обмін і чому вони з'явилися.
- Проєктування схеми обміну даними. За кожним потоком фіксуємо провідну систему, склад реквізитів, зіставлення номенклатури та контрагентів, ключі, за якими об'єкти зв'язуються між базами.
- Налаштування синхронізації. Обмін за розкладом і за подією, права службового користувача, розмір порцій і порядок черги — зростання каталогу не повинно розтягувати обмін на години.
- Обробка збоїв. Журнал обміну, повторна доставка, повідомлення відповідальним і контрольні точки для відкату: зупинка одного потоку не блокує решту.
- Приймальні перевірки на реальних операціях. Проганяємо наскрізні сценарії — замовлення з сайту, рахунок, оплата, повернення, новий контрагент — і звіряємо не факт запису, а збіг даних і звітів в обох системах.
- Передача в підтримку. Віддаємо документацію щодо схеми обміну, регламент ручних операцій, доступи та моніторинг, навчаємо співробітників і фіксуємо порядок ескалації при розходженнях.
Що залишається в проєкті: схеми обміну, ролі, регламенти
Інтеграція тримається не на коді обміну, а на описаних правилах: хто володіє довідником, що робити при конфлікті версії товару, які поля вважаються джерелом істини.
Поки ці відповіді живуть лише в головах розробників, будь-яке доопрацювання починається з археології, а зміна підрядника — з відновлення логіки за журналами обміну. Тому на прийманні передаємо пакет артефактів і перевіряємо кожен на живому сценарії:
- Карта відповідності полів — таблиця «поле на сайті ↔ об'єкт у Битрикс24 ↔ реквізит 1С» з типом, обов'язковістю та правилом перетворення: податок і одиниця виміру приводяться до довідника, а не передаються рядком.
- Схема потоків даних — за кожним об'єктом: напрямок обміну (товари, ціни, залишки, замовлення, статуси), періодичність, обсяг і сторона, чий запис стає головним.
- Політики доступу та ролі — службові облікові записи, їхні права на розділи й документи, порядок відкликання доступу та зміни ключів.
- Регламент при розходженнях — як фіксується конфлікт, чия версія перемагає, хто підтверджує ручну правку і як вона повертається в обмін.
- Документація щодо інтеграції — сценарії обміну, налаштування модуля, розклад завдань і залежності між ними.
- Інструкція з відновлення — перезапуск обміну за період, повторне вивантаження позиції, що зависла, що дивитися при зупинці черги.
- Журнал моніторингу — які помилки логуються і за якими ознаками черговий розуміє, що обмін деградував.
Пакет самодостатній: за ним інша команда відтворює обмін, не ставлячи питань авторові. Контрольний сценарій за кожним пунктом на прийманні потрібен, щоб документація залишилася робочою, а не формальною.
Кейс: як прибрали розходження залишків між сайтом і порталом
Що було до переробки
Магазин на боці сайту та портал жили на нічних вивантаженнях: каталог із 12 000 позицій обмінювався раз на добу, тому залишки на вітрині відставали майже на робочий день.
Оператори щоранку вручну звіряли розходження за 3–4 групами товарів, на кожну йшло 40–50 хвилин, і все одно до обіду розходилося 8–12% позицій.
Ціна помилки — подвійні продажі та замовлення, які доводилося правити вже після оформлення. Частка таких замовлень сягала 18%, а покупець дізнавався про нестачу товару через годину-півтори після оплати.
Що змінили і що вийшло на виході
Обмін перевели на подієву схему: зміна залишку в обліковій системі одразу йде на портал, а підтвердження прийому фіксується в журналі обміну.
Черга з повторним надсиланням при збої та ідемпотентна обробка прибрали подвійне списання — повторне повідомлення не створює друге замовлення і не знімає залишок двічі. Резерв тепер ставиться в момент оформлення, тому вітрина та портал показують те саме число.
Метрики після: розходження залишків — 0,3% позицій замість 8–12%, планові звіряння скоротилися з чотирьох до одного вибіркового на тиждень.
Замовлення з ручною правкою — 1–2% замість 18%, час підтвердження замовлення впав з 40–50 хвилин до пари хвилин, а навантаження на операторів змістилося з перерахунку чисел на роботу з постачальниками.
Чим обмін через проміжну базу відрізняється від прямого зв'язку
Прямий зв'язок сайту та порталу — це звернення до зовнішньої системи в момент операції: замовлення на сайті одразу йде в обліковий контур.
Схема дає мінімальну затримку, але буфера в неї немає: якщо контур недоступний або відповідь прийшла з помилкою на середині пакета, операція губиться або залишається в невизначеному стані.
Проміжна база ставить між сайтом і порталом чергу: обидві сторони пишуть і читають лише її, а зовнішній контур підключається асинхронно.
Запис фіксується зі статусом і міткою часу, надсилання підтверджується окремим кроком — при недоступності зв'язку накопичене просто чекає і йде після відновлення.
Стійкість обміну тримається на конкретних механізмах: ключ ідемпотентності не дає продублювати замовлення при повторному надсиланні даних, повтори з наростаючою паузою не добивають сервіс, що впав, окрема черга зберігає записи, які не вдалося провести. Ціна — затримка на цикл обміну і зайвий вузол у схемі, який потрібно обслуговувати.
Діагностика збоїв у буферній схемі зводиться до журналу: видно, на якому кроці застряг запис, скільки було спроб і що відповіла приймальна сторона. У прямому зв'язку розбір іде за логами обох систем і часто впирається у відсутність спільної ідентифікації запису.
Тому вибір — не «що сучасніше», а що критичніше: миттєва реакція на простому потоці або гарантія доставки там, де дубль і втрата дорожчі за цикл очікування.
Часті технічні сумніви перед стартом
Сумніви перед стартом зазвичай стосуються не самої ідеї обміну, а того, як він поведеться на вже наповнених базах, чужому коді та при збоях зв'язку. Нижче — питання, які ставлять майже на кожному проєкті інтеграції Битрикс24 і 1С, і короткі відповіді інженерів.
У нас уже наповнені каталог і портал — дані не загубляться?
Обмін зіставляє записи за зовнішнім ідентифікатором, а не за назвою, тому перший сеанс — це звіряння, а не перезапис. Далі передаються лише зміни: наявні позиції, ціни та контрагенти залишаються на місці, дублі не створюються.
На сайті працює чужий код — доведеться все переписувати?
Обробники інтеграції підключаються до штатних подій і не чіпають шаблон і логіку вітрини. Окремо перевіряємо ділянки, де сторонній код пише в ті самі сутності: такі точки розводимо за пріоритетами, інакше з'являються розходження.
Що буде, якщо зникне зв'язок між сайтом і порталом?
Непідтверджений пакет залишається в черзі і йде повторно; повтор розпізнається за зовнішнім ключем, тому дублі в базах не з'являються. Коли канал відновиться, обмін наздожене накопичене, а журнал покаже, що вже застосовано і що чекає на надсилання.
Обмін сповільнить роботу менеджерів у порталі?
Якщо обмін іде порціями і лише за змінами, а важкі звіряння винесені за межі робочого дня, користувач різниці не помічає. Картки, угоди та звіти відкриваються зі звичайною швидкістю.
Оновлення порталу зламають інтеграцію?
Обмін будується на штатних механізмах і не змінює ядро, тому оновлення порталу проходять за звичайним регламентом. Перед перенесенням на робочий контур проганяємо обмін на копії — це виловлює несумісність до того, як її побачать користувачі.
Обговоримо інтеграцію Битрикс24: з чого починаємо
Щоб повернутися з оцінкою обсягу робіт і планом впровадження, повний аудит на першому дзвінку не потрібен. Достатньо обговорити задачу інтеграції предметно: показати облікову систему, поточний обмін і доступи, решту наші інженери зберуть самі. Що варто підготувати до розмови:
- Редакція та ступінь доопрацювання конфігурації: обмін із типовою і з сильно переписаною обліковою системою проєктується по-різному.
- Перелік об'єктів, які мають їхати між сайтом, порталом і обліком: номенклатура, ціни, склади, залишки, замовлення, рахунки, контрагенти, статуси угод.
- Напрямок і частота обміну: тільки вивантаження каталогу раз на добу або двосторонній потік замовлень і статусів із затримкою в хвилини.
- Як обмін працює зараз — регламентне завдання, вивантаження у файл, веб-сервіс — і що саме перестало влаштовувати.
- Доступи для аудиту: тестовий контур облікової системи, окремий портал або адміністративний доступ до бойового з обмеженнями, доступ до сервера сайту та логів обміну.
- Обсяги: скільки позицій у каталозі, скільки замовлень на добу, скільки активних користувачів порталу — від цього залежить вибір механіки синхронізації.
- Хто на вашому боці ухвалює рішення і підтвердить правила зіставлення довідників, щоб дублі та розходження не спливли на етапі розгортання.
За цими ввідними ми називаємо механіку обміну, порядок розгортання та строки. Наступний крок — опишіть задачу в зручному вигляді, і ми повернемося з оцінкою та планом робіт.