Що саме потрібно синхронізувати?
Замовлення, клієнт, оплата, товар і залишок — різні сутності. Для кожної фіксуємо джерело, напрямок обміну, момент оновлення та дію при помилці. Наприклад, ціною керує облікова система, а менеджер змінює контакт для доставки в CRM. Такі зміни не повинні безумовно перезаписувати одна одну.
- Зовнішній номер замовлення та позиції з варіантами товару.
- Контакти й адреса доставки з потрібними правами доступу.
- Статуси, оплати, часткові відвантаження та повернення.
- Правило доступності товару: фізична кількість не завжди дорівнює доступній.
Сценарій: повторний запит створив дубль замовлення
Магазин надіслав замовлення, але не отримав відповідь і повторив запит. Якщо кожна спроба створює новий запис, менеджер бачить дві покупки. Проєктуємо перевірку за стійким зовнішнім ідентифікатором, журнал обробки та безпечний повтор. Просте порівняння телефону й суми не підходить: клієнт може справді зробити два однакові замовлення.
Сценарій: повернення відновило неправильний залишок
Покупець повернув одну позицію, а обмін позначив поверненим усе замовлення. Окремо моделюємо кількість по рядках, рух грошей і стан товару. Повернення коштів не означає, що товар уже придатний до продажу. Перед запуском перевіряємо часткове повернення, обмін розміру та переміщення в зону перевірки як різні події.
Готовий конектор чи власна інтеграція?
Спочатку перевіряємо наявний конектор на ваших сценаріях. Якщо він не підтримує потрібні поля або винятки, оцінюємо API та окрему логіку. Для KeyCRM, Skynum, ERPNext, HubSpot, Pipedrive та Zoho CRM звіряємо доступні об’єкти й операції з документацією. Для Dynamics 365 уточнюємо конкретний продукт. Жодну пару систем не вважаємо сумісною без перевірки доступів, тарифів і обмежень.
Що відбувається, коли одна система недоступна?
Домовляємося, які операції можна поставити в чергу, хто отримає повідомлення й як звірити дані після відновлення. Повтор має не множити замовлення, а завершувати незавершений обмін. Для залишків окремо погоджуємо допустиму затримку й поведінку магазину при застарілих даних. Обіцянка «завжди в реальному часі» без цих правил не розв’язує проблему.
Що входить у приймання інтеграції?
Перевіряємо не лише успішне створення одного замовлення, а й повтори, зміни та відмови. Результат роботи — погоджений обмін, перевірені сценарії й зрозуміла інструкція для відповідального.
- Повторна й несвоєчасна доставка події.
- Часткова оплата, скасування та повернення.
- Відсутній артикул або невідомий статус.
- Відновлення після збою та контроль пропущених записів.