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