06 / Напрями
Обмін між системами
Зв'язка CRM, складу, банку, вітрини і сторонніх сервісів так, щоб дані не вносили двічі.
Компаніям, де одна й та сама картка живе в кількох програмах.
Обмін
Системи
Звідки
Пошта
Куди
Склад
Слід
Журнал
З чого складається
Що входить у контур
- 01
Хто головний за полем
У кожного факту один господар: ціна живе в обліку, статус замовлення — у вітрині, контакт — у CRM. Решта читає.
- Список полів, які їдуть
- Звідки пишуть і хто лише читає
- Що робити, якщо обидва джерела змінили одне поле
- 02
Канал
API, вебхук або черга — за тим, як система вміє віддавати дані, а не «як модніше».
- Що приходить саме
- Що доводиться забирати за розкладом
- Який обсяг буває в годину пік
- 03
Збій
Пакет, який не дійшов, не зникає мовчки. Він чекає і пробує ще раз.
- Повтор із паузою
- Пакет, який уже не можна повторювати
- Сигнал, якщо черга стала
- 04
Журнал
За номером замовлення або картки видно: пішло, дійшло, відмовлено і чому.
- Запис за кожною спробою
- Пошук за номером
- Хто може перезапустити обмін
- 05
Чого не зв'язуємо
Зайва зв'язка плодить розбіжності. Поля, які ніхто не читає, не тягнемо.
- Системи, які лишаються ручними
- Поля поза обміном
- Як перевірити обмін на копії, до бойових даних
Що робимо
- 01Карта, хто головний за кожним полем
- 02API, вебхуки і черги
- 03Підключення обліку, банків і вітрин
- 04Повтор при збої, а не тиха втрата пакета
- 05Журнал, за яким видно, що не дійшло
Як ідемо
- 01Аудит систем
- 02Схема обміну
- 03Збірка
- 04Прогін на живих даних
- 05Опис для команди
На чому
- REST
- GraphQL
- Node.js
- Python
- PostgreSQL
Орієнтир за строком
Один обмін — від тижня. Кілька систем із конфліктами даних — від місяця.
На виході
Факт вноситься один раз і доїжджає туди, де на нього чекають.
Що зазвичай пізніше
Двостороннє редагування одного поля в трьох системах і «історичне перенесення за п'ять років» робимо окремо, після живого обміну поточних фактів.