Синхронізація CRM з BAS працює стабільно, коли для кожного поля визначено головну систему, товари зіставлено за сталим ідентифікатором, а обмін записує успішні й відхилені записи. Розбіжність у залишку чи ціні шукайте на одному товарі: від запису в BAS до відповіді API CRM і значення в картці.
У CRM товар є в наявності, а склад уже показує нуль. Причиною можуть бути правила резервування, помилка зіставлення, затримка або збій інтеграції. Нова CRM не гарантує правильних даних: вона показує те, що отримала та змогла обробити.
Як BAS обмінюється даними з CRM?
Платформа BAS має кілька механізмів обміну: HTTP-сервіси, веб-сервіси, стандартний інтерфейс OData, файловий обмін і обмін повідомленнями. Їх перелічено в розділі 17 документації платформи. Це можливості платформи, а не готовий конектор до конкретної CRM. Налаштуванню веб-сервера для OData і HTTP-сервісів у посібнику адміністратора BAS присвячено окремі розділи 8.6 і 8.7.
Обмеження має і бік CRM. Наприклад, у довідці KeyCRM вказано ліміт до 20 запитів на хвилину за API-ключем. Після перевищення запити отримують помилку «429 Too Many Requests», а за регулярне порушення доступ до API можуть заблокувати. Залишок там оновлюють для складу за артикулом (sku) або за ідентифікатором варіанту товару (offer_id, він не дорівнює product_id). Якщо передати обидва, система спершу шукає за ідентифікатором, потім за артикулом.
Наша рекомендація для такої інтеграції: тримати темп у межах ліміту, а після 429 повторювати запит із паузою. Інші помилки обробляти за їхньою причиною, а не простим повтором. Якщо товари зіставляються за артикулом, він має збігатися в BAS і CRM.
Яка система головна для кожного поля?
Для ціни, залишку, контакту й статусу головною може бути різна система. Наприклад, ціни й залишки веде BAS, а контакти й статуси угод CRM. Запишіть, хто має право змінювати поле та в який бік воно передається. Двостороння синхронізація без правила конфлікту здатна повернути старе значення поверх нового.
Як простежити один запис між CRM і BAS?
Оберіть товар із відомою розбіжністю. Перевірте його ідентифікатор у BAS, вихідні дані інтеграції, відповідь API та запис у CRM. Назва товару не завжди придатна як ключ: вона може змінюватися або повторюватися.
Зверніть увагу на варіанти товару, одиниці виміру, склади й типи цін. Однакове число в різних полях може означати різні речі.
Як зрозуміти, що обмін справді пройшов?
Дивіться на час останнього успішного оновлення запису, а не лише на факт запуску задачі. Якщо частину записів API відхилив, зелений статус усього імпорту вводить в оману. Помилки мають містити достатньо контексту для повторної обробки. Як налаштувати таку перевірку після запуску, ми описали в статті про моніторинг автоматизації.
Чому після збою зʼявляються дублікати?
Після таймауту інтеграція може надіслати ту саму подію ще раз. Це не повинно створювати друге замовлення чи повторний рух залишку. Потрібні сталі ідентифікатори подій та перевірений порядок відновлення.
Що підготувати для діагностики?
Достатньо кількох прикладів: правильний запис, запис із помилкою та очікуване значення. Додайте назви систем, напрям обміну й час виникнення розбіжності. Не надсилайте паролі або повні клієнтські бази через публічну форму.
Часті питання
Чи можна синхронізувати CRM з BAS без ручного вивантаження файлів?
Так, документація BAS описує автоматичні механізми обміну, наприклад HTTP-сервіси та стандартний інтерфейс OData; з боку CRM потрібен API. Конкретну схему обирають під конфігурацію BAS і CRM. Якщо обмін іде файлами, радимо окремо перевіряти, які записи завантажились.
Яку систему вважати головною для залишків і цін?
Ми радимо обирати ту, де ці значення створюються й змінюються за правилами обліку, і закріплювати за кожним полем одну відповідальну систему. Якщо поле змінюють обидві, домовтеся про правило конфлікту заздалегідь.
Як часто запускати синхронізацію?
Залежить від швидкості змін і лімітів API CRM. Рекомендована схема: якщо системи підтримують події, передавати зміни ними через чергу з урахуванням ліміту, а повну звірку залишків робити рідше, за розкладом.
Чому CRM знову показує старе значення після оновлення?
Можливі причини, які варто перевірити за журналом обміну: двостороння синхронізація без правила конфлікту, коли старіше значення записується пізніше за новіше, або зіставлення з іншим товаром через назву замість ідентифікатора.
Джерела
- Business Automation Framework 8.3.23. Документація, розділ 17 «Інтеграція із зовнішніми системами»: its.bas-soft.eu (дата доступу 05.10.2026).
- BAS. Посібник адміністратора, розділ 8 «Настройка веб-серверів для роботи з BAS», підрозділи 8.6 і 8.7: its.bas-soft.eu (дата доступу 06.10.2026).
- KeyCRM, «Як працювати з товарами та залишками в API»: help.keycrm.app (дата доступу 05.10.2026).
- KeyCRM, «Де отримати API ключ»: help.keycrm.app (дата доступу 05.10.2026).
Ми розбираємо такі задачі в напрямі інтеграцій CRM, ERP і BAS. Для магазину корисно також перевірити весь процес обробки замовлення, щоб виправлення одного поля не залишило проблему далі по ланцюжку.