Налаштування обміну 1С:Управління нашою фірмою (УНФ) і 1С-Бітрікс
УНФ — вибір малого бізнесу, який прагне вести CRM, склад і продажі в одному місці без зайвої складності ERP. Інтеграція з Бітрікс тут працює інакше, ніж з УТ або КА: у УНФ немає повноцінного механізму обміну CommerceML у старому стилі, зате є REST API і Bitrix Drive — офіційний конектор від 1С.
Два шляхи інтеграції УНФ з Бітрікс
Шлях 1: CommerceML (класичний). УНФ підтримує стандартний протокол обміну через /bitrix/admin/1c_exchange.php. Вивантажуються номенклатура, ціни, залишки, приймаються замовлення. Працює, але з обмеженнями: немає характеристик у повному обсязі, немає серійного обліку, документи CRM не передаються.
Шлях 2: REST API + вебхуки. УНФ починаючи з версії 1.6 має вбудований HTTP-сервіс. Бітрікс може опитувати його або отримувати push-повідомлення про зміни. Цей шлях гнучкіший, але вимагає розробки на обох сторонах.
Для більшості завдань (каталог + замовлення) достатньо CommerceML. REST потрібен, коли необхідно передавати нестандартні об'єкти: угоди CRM, завдання, документи.
Налаштування CommerceML у УНФ
Розділ: Компанія → Інтеграція → Обмін з сайтом.
Параметри:
- Адреса сайту та облікові дані
- Номенклатура: вибрати групи для вивантаження
- Ціни: вид ціни (роздрібна / оптова)
- Залишки: по яких складах
Особливість УНФ: номенклатура в УНФ може мати «варіанти» — аналог характеристик у УТ. Варіанти вивантажуються в CommerceML як окремі позиції з ознакою ХарактеристикаНоменклатури. Бітрікс читає їх і створює торговельні пропозиції (SKU). Цей ланцюжок працює, якщо варіанти не мають вкладених залежностей (наприклад, ціна варіанту не залежить від іншого варіанту).
Замовлення з Бітрікс у УНФ
Замовлення створюються в УНФ як «Замовлення покупця». Контрагент створюється автоматично за даними із замовлення.
Критичний момент: статуси. В УНФ замовлення проходить статуси: Нове → В роботі → Виконано / Скасовано. У Бітрікс — власний ланцюжок статусів. Відповідність налаштовується у вузлі обміну. Якщо не налаштувати — замовлення в УНФ зависатимуть у статусі «Нове».
Зворотна синхронізація статусів. Коли менеджер у УНФ змінює статус замовлення — ця зміна повинна потрапити до Бітрікс. Стандартний обмін це підтримує: при наступному сеансі обміну статус замовлення оновлюється в Бітрікс. Але є затримка — рівна інтервалу обміну (зазвичай 5–15 хвилин).
Кейс: УНФ + Бітрікс у сфері послуг
Сервісний центр з ремонту техніки: в УНФ ведеться CRM (заявки клієнтів, історія ремонтів), на сайті — форма заявки та особистий кабінет клієнта.
Завдання: заявка з сайту повинна потрапляти в УНФ як «Звернення», клієнт повинен бачити статус ремонту в особистому кабінеті на сайті.
Рішення: використали REST API УНФ. При відправці форми на сайті:
- Бітрікс створює замовлення у своїй системі
- Скрипт робить POST-запит до HTTP-сервісу УНФ: створює звернення
- УНФ повертає ID звернення, Бітрікс зберігає його в користувацькому полі замовлення
Для зворотної синхронізації статусів — вебхук з УНФ: при зміні статусу звернення — POST-запит на endpoint Бітрікс, який оновлює статус замовлення.
Затримка статусної синхронізації: 0 (миттєво через хук) замість 5 хвилин при polling.
Обмеження УНФ при інтеграції
| Параметр | УНФ | УТ 11 |
|---|---|---|
| Характеристики номенклатури | Варіанти (обмежено) | Повноцінні характеристики |
| Кілька складів | Так | Так |
| Серійний облік | Так (базово) | Так (розширено) |
| REST API | Так | Обмежено |
| CRM-об'єкти в обміні | Тільки через REST | Ні |
УНФ добре підходить для інтеграції, якщо каталог невеликий (до 20 тис. позицій) і немає складних характеристик. Якщо бізнес зростає — закладіть можливість міграції на КА або УТ без переробки сайту (зберігайте XML_ID номенклатури).