Інтеграція МойСклад із сайтом: де ламається синхронізація
Інтеграція МойСклад із сайтом майже ніколи не ламається «повністю» — вона деградує точково, і це небезпечніше.
Синхронізація залишків іде за розкладом, а не в момент покупки: між вивантаженням і оформленням замовлення минає вікно, у якому сайт показує товар у наявності, хоча на складі він уже проданий.
Звідси подвійні продажі, ручні повернення та клієнти, яким доводиться пояснювати, чому оплачене замовлення не поїде.
Друга тиха поломка — розбіжність номенклатури. Артикули в обліковій системі та на сайті живуть за різними правилами: десь змінювали вручну, десь товар завели двічі, десь одиниці виміру не збіглися.
Обмін замовленнями при цьому продовжується, але позиції зіставляються за назвою — і замовлення йде в облік із «нульовим» рядком, який менеджер ловить уже після підтвердження клієнту.
Третій клас збоїв — втрата подій. Якщо обмін побудований на періодичному опитуванні без журналу змін, будь-яка правка ціни чи залишку між двома проходами просто зникає.
Сайт і облікова система розходяться наростаючим підсумком, і за кілька тижнів ніхто не може сказати, яка сторона «правильна» — доводиться звіряти вручну.
Ціна цих збоїв рахується не в помилках інтеграції, а в зірваних замовленнях: клієнт оформив, оплатив, чекає — і отримує відмову. Нижче розбираємо, як кожен із цих збоїв закривається на рівні схеми обміну, а не ручними правками.
Що дає налаштування обміну: товари, замовлення, залишки
Синхронізація товарів: каталог перестає розходитися з полицею
Обмін витягує номенклатуру, ціни, одиниці виміру та характеристики з облікової системи в каталог сайту. Зіставлення відбувається за зовнішнім ідентифікатором позиції, а не за назвою — перейменування або зміна артикулу не породжує дублів і не розриває зв'язків.
На виході каталог на кілька тисяч позицій сходиться з обліковим за хвилини, а не за нічний прогін, і правка ціни з'являється на сайті без ручного вивантаження файлу.
Вивантаження замовлень: документ створюється один раз
Оформлене замовлення йде в облікову систему окремим документом зі складом, знижками та даними покупця.
Ідемпотентність за номером замовлення закриває головний ризик — повторне надсилання при обриві зв'язку: дублікатів в обліку не з'являється, а статус на сайті підтягується назад після збирання та відвантаження. Клієнт бачить рух замовлення, менеджер не звіряє дві бази вручну.
Актуальні залишки: продаж без відмови
Залишки за складами оновлюються частіше за каталог і з пріоритетом — позиція з нульовим залишком переходить у «під замовлення» або ховається за правилом.
Це знімає клас відмов «оплатив, а товару немає»: частка скасованих замовлень падає, а резерв під оформлений кошик не дає продати одну одиницю двічі.
Режим обміну та розклад синхронізації
Обмін будують на штатному програмному інтерфейсі облікової системи: події (вебхуки) для замовлень і залишків плюс плановий обхід для каталогу. Розклад задається під ритм продажів: залишки — кожні кілька хвилин, каталог — рідше, важкі вивантаження — у вікно низького навантаження. Черга з повторами тримає обмін при недоступності однієї зі сторін і не втрачає зміни.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Подієвий обмін (вебхуки) | Замовлення, залишки, часті точкові зміни | Потрібна обробка повторів і недоставлених подій |
| Плановий обхід за розкладом | Каталог, ціни, масові оновлення | Затримка дорівнює інтервалу обходу |
| Гібрид: події + обхід | Магазини з активними продажами | Складніше налаштування черги та правил пріоритету |
| Прямий обмін через проміжну базу | Високе навантаження, кілька каналів продажів | Потребує окремого сервісу та його підтримки |
МойСклад віддає товари, залишки та замовлення через документований інтерфейс — цього достатньо, щоб побудувати обмін без ручних вивантажень і сторонніх надбудов.
Як ми впроваджуємо обмін: від аудиту до передачі
Обмін між обліковою системою та сайтом майже ніколи не зводиться до «увімкнути синхронізацію».
Потрібно заздалегідь домовитися, що вважається джерелом істини щодо залишків, як зіставляються номенклатура та склади, що робити із замовленням, яке на сайті оформлено в момент, коли товар уже списано в залі. Тому роботу ведемо етапами, і кожен завершується артефактом, який можна перевірити.
- Аудит облікової системи. Дивимося довідники номенклатури, склади, ціни та типи цін, історію рухів, дублі та «сміттєві» позиції. Фіксуємо, які сутності взагалі готові до обміну, а які доведеться нормалізувати до старту.
- Проєктування схеми обміну. Визначаємо напрямок потоків, частоту та тригери: залишки й ціни йдуть на сайт, замовлення — в облікову систему, статуси — назад. Прописуємо правила зіставлення за артикулом і зовнішнім ідентифікатором, поведінку при конфлікті та при видаленні позиції.
- Налаштування синхронізації. Реалізуємо обмін через штатні механізми та API, ставимо обробку помилок і повторні спроби, обмежуємо навантаження при масових вивантаженнях, щоб каталог не «завмирав» у години пік.
- Складання тестового контуру. Копія каталогу та облікової бази, де проганяємо сценарії: зміна ціни, списання залишку, оформлення та скасування замовлення, повернення, поява нової позиції. Дивимося, що розбіжностей між системами не залишається.
- Перевірка на реальних даних. Переносимо обмін на робочий контур з обмеженим набором товарів, звіряємо залишки та замовлення порядково, заміряємо, за скільки проходить повний цикл і як система поводиться при обриві зв'язку.
- Регламент і моніторинг. Налаштовуємо оповіщення про збої обміну та розбіжності, описуємо, що робить оператор при помилці, щоб проблема не чекала розробника.
- Передача документації. Віддаємо схему потоків, карту зіставлення полів, інструкції для менеджерів і доступи до налаштувань.
Такий порядок дає передбачуваний результат: обмін запускається без зупинки продажів, а розбіжності видно на тестовому контурі, а не в перший день роботи. Опишіть вашу облікову систему та каталог — повернемося з оцінкою та планом робіт.
Чим відрізняється обмін за розкладом від обміну в реальному часі?
Інтеграція МойСклад із сайтом майже завжди починається з одного питання: як часто ганяти дані. Обмін за розкладом запускається за таймером — раз на 5, 15 або 60 хвилин — і забирає зміни пакетом.
Синхронізація в реальному часі працює інакше: подія в обліковій системі (створили замовлення, змінили залишок, оновили ціну) одразу йде на сайт через вебхук або потік змін. Різниця не в «сучасності», а в тому, які затримки і яке навантаження ви готові прийняти.
Затримка оновлення — ключова метрика вибору. При обміні за розкладом залишок на вітрині відстає на інтервал таймера: якщо товар продано в залі, а сайт оновиться через годину, покупець оформить замовлення на те, чого немає.
У реальному часі залишок сходиться за секунди, але кожна подія — це окремий запит до сайту і до облікової системи. При асортименті в кілька тисяч позицій і активних продажах потік подій стає щільним, і сайт починає витрачати ресурси на приймання оновлень замість віддачі сторінок.
Частота обміну — це компроміс між свіжістю даних і навантаженням на сайт. Практика така: залишки і ціни — часто (кожні 1-5 хвилин або за подією), номенклатура і описи — рідко (раз на добу або за фактом правки), замовлення — одразу, бо втрачене замовлення дорожче за зайвий запит.
Гібридна схема закриває майже всі сценарії: критичні для продажу дані йдуть у реальному часі, важкі довідники — пакетно за розкладом.
Окремо варто врахувати пікові навантаження. Масове оновлення цін або надходження товару за розкладом може збігтися з вечірнім трафіком і завалити відгук сайту. Тому обмін виносять у чергу, обмежують число одночасних запитів і розводять важкі задачі за часом.
Тоді синхронізація не заважає покупцям, а дані залишаються актуальними настільки, наскільки вимагає бізнес.
Кейс: як ми прибрали подвійні продажі під час обміну
Клієнт — роздрібна мережа з інтернет-магазином на виділеному сервері та обліком у хмарній системі. Обмін був побудований на регулярному вивантаженні файлів: сайт забирав залишки раз на годину, замовлення йшли назад тією ж дорогою.
При піковому навантаженні — розпродаж, надходження нової партії — вікно розсинхронізації розтягувалося, і два покупці оформлювали останню одиницю товару.
Частка замовлень з розбіжністю залишків сягала 8%, а на розборі скасувань і повернень менеджери витрачали по кілька годин на день.
Що саме ламалося
Корінь був не в самому факті обміну, а в його асинхронності та відсутності блокування на момент оформлення. Сайт резервував товар лише після того, як замовлення долітало до облікової системи, — а до цього моменту залишок на вітрині залишався незмінним.
Друга проблема — конфлікти при одночасному записі: якщо менеджер правив картку в обліковій системі, а сайт у цей же момент надсилав замовлення, частина змін затиралася.
Що змінили
Ми перевели обмін на подієву модель: облікова система сама повідомляє сайту про зміну залишку, а сайт резервує товар у момент додавання до кошика та підтверджує резерв при оформленні.
Черга повідомлень згладжує піки й гарантує, що жодна подія не загубиться при короткому розриві зв'язку. Конфлікти запису розвели за пріоритетами: довідкові дані — за обліковою системою, оперативні резерви — за сайтом.
| Метрика | До | Після |
|---|---|---|
| Частка замовлень з розбіжністю залишків | до 8% | менше 0,3% |
| Затримка оновлення залишку | до 60 хвилин | секунди |
| Скасування з причини «немає в наявності» | регулярні | поодинокі |
| Ручний розбір конфліктів | щодня | за винятками |
МойСклад у цій схемі залишається джерелом істини щодо номенклатури та залишків — сайт лише своєчасно на неї реагує. Такий підхід прибирає сам ґрунт для подвійних продажів: покупець бачить актуальний залишок, а резерв фіксується до підтвердження оплати.
Сумніви щодо сумісності, міграції та відкату обміну
Інтеграція МойСклад рідко викликає питання на етапі «підключити обмін» — вони з'являються пізніше: що буде з накопиченою історією замовлень, як обмін уживеться з поточним каталогом і що робити, якщо після запуску випливе розбіжність залишків. Розбираємо ці сумніви по суті.
Що якщо на сайті вже є своя база товарів і замовлень? Обмін не вимагає чистої установки: на першому проході зіставляємо позиції за артикулом і штрихкодом, конфлікти за залишками та цінами виводимо окремим звітом, а не «затираємо» мовчки. Історія замовлень переноситься окремим проходом, щоб не ламати вже зібрану аналітику.
Що якщо обмін зламається вночі? Кожна операція йде через чергу з повторними спробами, а розбіжності фіксуються в журналі — при збої видно, яке саме замовлення або залишок не синхронізувався.
План відкату будується на резервній копії каталогу та замовлень перед першим запуском: повернення до попереднього стану — це перемикання на збережений знімок, а не ручний розбір.
Наскільки складно повернутися до попередньої схеми роботи, якщо обмін не підійде?
Відкат продумується до запуску: знімок каталогу та замовлень, зафіксовані точки перемикання і зрозумілий порядок повернення. Якщо після тестового періоду вирішите зупинитися, повертаємося до вихідного стану без втрати даних, накопичених за час обміну.
Що якщо потрібно буде обмежити доступ? Ролі та права налаштовуються окремо: обмін працює через виділеного користувача з мінімально потрібними правами, а не через обліковий запис адміністратора. Це ж спрощує аудит — видно, які дії виконував обмін, а які людина.
Після здачі замовник отримує на руки:
- схему обміну з переліком сутностей і напрямків синхронізації;
- конфігурацію зіставлення товарів, цін і залишків;
- регламент обробки конфліктів і розбіжностей;
- опис плану відкату та точок повернення до попереднього стану;
- матрицю доступів і ролей для обміну;
- журнал синхронізації з прикладами розбору збоїв;
- документацію з обміну для команди, яка буде його супроводжувати.
Опишіть вашу поточну схему — які дані вже накопичені, як влаштований каталог і хто працює із замовленнями. Повернемося з оцінкою та планом міграції під ваш випадок.
Терміни впровадження обміну за етапами
Терміни залежать від кількості складів, каналів продажу та від того, наскільки брудні дані в обліковій системі. Нижче — орієнтир за етапами для типового проєкту: каталог до кількох тисяч позицій, один сайт, один склад.
Етапи йдуть послідовно, але частина робіт із підготовки довідників відбувається паралельно з обміном.
Разом для типового проєкту — від двох до чотирьох тижнів. Основний час іде не на сам обмін, а на приведення довідників до ладу: поки номенклатура дублюється і ціни лежать у різних місцях, будь-який обмін даватиме розбіжності.
Що якщо в нас кілька складів і точок продажу? Додається етап налаштування правил пріоритету складу та логіки резерву — плюс приблизно тиждень.
Що якщо сайт уже працює і обмін потрібен без зупинки продажів? Тестовий запуск іде на копії, робочий контур перемикаємо в один короткий інтервал, зазвичай уночі або в затишші.
Чи можна прискорити? Так, якщо довідники вже чисті й правила відповідності очевидні — етап підготовки скорочується майже вдвічі.
Опишіть вашу конфігурацію складів і каналів продажу — повернемося з оцінкою та планом за етапами.
