Інтеграція KazanExpress: де ламається обмін товарами
Обмін товарами з маркетплейсом — це не разове вивантаження каталогу. Товари, ціни та залишки одночасно живуть у двох системах, і розсинхрон між ними починається з перших хвилин після запуску.
Далі він лише накопичується, якщо обмін не вибудуваний як постійний процес із перевіркою результату кожної операції.
Розходження залишків — найчастіша точка відмови. Товар продано на майданчику, а в обліковій системі він усе ще рахується в наявності; слідом надходить друге замовлення, яке нічим закрити.
Скасування з вини продавця знижує рейтинг, майданчик рідше показує картки у видачі, і втрати зростають уже не від однієї помилки, а від їхнього потоку.
Загублені замовлення з'являються там, де зіставлення позицій тримається на збігу назв або артикулів, уведених вручну. Замовлення надходить, але не знаходить товар в обліку й залишається поза обробкою, доки його не знайдуть під час звірки.
Ручне вивантаження товарів таблицями закриває це до певного обсягу: на сотні позицій терпимо, на кількох тисячах щоденна звірка з'їдає робочий час і все одно пропускає розходження.
Помилки в картках товару — окремий клас втрат. Неправильні одиниці виміру, габарити й обов'язкові атрибути категорії призводять до відхилення картки або до зниження її у видачі, а за невідповідні дані майданчик накладає обмеження на акаунт.
Спільне в цих збоях одне: обмін іде за розкладом, без розбору відповідей майданчика й без журналу операцій. Нижче розбираємо, як це закривається на рівні архітектури обміну.
Що дає постійний обмін замовленнями та залишками
Коли залишки в обліковій системі та на вітрині маркетплейсу живуть окремо, кожне замовлення проходить через людину: позицію звіряють очима, наявність підтверджують вручну, дані переносять в облік.
За потоку в сотні замовлень на день це дає затримку в кілька годин і передбачуваний клас відмов — продаж того, чого на складі вже немає, і скасування з вини продавця.
Постійний обмін знімає цей прошарок. Залишок резервується в момент оформлення замовлення, а не в момент збирання, тому позиція зникає з вітрини Магнит Маркет одразу після того, як її перестало вистачати.
Замовлення потрапляє в облік за хвилини, а не до кінця зміни, і далі йде за статусами без участі оператора.
Частка автоматично оброблених позицій на такому контурі — 95–97%, ручні операції залишаються лише на нештатних випадках: розходження через брак, часткове повернення, замовлення з нестандартною доставкою.
Синхронізація залишків працює у двох режимах — пакетне оновлення за розкладом і точкове, одразу після руху по складу. Саме точковий режим тримає актуальність наявності в години пік, коли пакетне оновлення фізично не встигає.
Обмін іде подієво: платформа надсилає повідомлення про нове замовлення, наша сторона підтверджує приймання, а при обриві зв'язку запит повторюється.
Повторна доставка однієї й тієї самої події не створює дубль в обліку — це закладається на етапі проєктування, а не лікується звіркою постфактум. Окремо ведемо журнал розходжень: якщо залишок на вітрині та в обліку розійшлися, видно, на якому кроці це сталося.
Способи підключення: програмний обмін, файли, особистий кабінет
Способи підключення різняться не зручністю інтерфейсу, а тим, скільки ручної роботи залишається в ланцюжку «замовлення → відвантаження → статус».
Перед вибором фіксуємо три параметри: потік замовлень на добу, частоту зміни залишків і наявність відкритого інтерфейсу в обліковій системі. Від цих відповідей залежить, який режим обміну взагалі має сенс.
| Спосіб | Коли підходить | Що обмежує |
|---|---|---|
| Програмний обмін даними (API) | Сотні замовлень на добу, потрібні актуальні залишки й автоматичні статуси | Потрібен сервіс-посередник: ліміти запитів, повтори при збоях, журнал операцій, тестовий контур |
| Вивантаження файлом | Невеликий потік, оновлення раз на добу, закрита облікова система | Затримка між вивантаженнями, розходження залишків, звірка вручну, статус надходить із запізненням |
| Робота через особистий кабінет | Поодинокі продажі або запуск без доопрацювань | Ручне введення, не масштабується, помилки введення, немає зв'язку зі складом |
На практиці виграє змішаний режим: замовлення та залишки йдуть програмним обміном, каталог і ціни оновлюються файлом за розкладом, а рідкісні правки карток роблять у кабінеті.
Так ми не платимо складністю там, де потік маленький, і не впираємося в ручну роботу там, де він зростає.
Обмеження обміну проговорюємо заздалегідь. У Магнит Маркет (раніше KazanExpress) правила обміну й модерації змінюються, тому частину обмежень знімаємо на своїй стороні: черга повторних відправлень, захист від дублів замовлень, журнал помилок із зрозумілим розбором.
Порядок робіт: від аудиту облікової системи до передачі
Обмін з KazanExpress (Магнит Маркет) — не «увімкнути модуль», а проєкт, де помилка видна вже першого дня: розійшлися залишки, приїхав дубль замовлення, загубився статус відвантаження. Ведемо роботи фіксованим маршрутом — від інвентаризації обліку до передачі рішення вашій команді.
- Аудит облікової системи. Дивимося, де живуть довідник товарів, залишки й ціни, які системи вже обмінюються даними і де замовлення досі правлять вручну.
- Проєктування потоків даних. Визначаємо сутності, які ходять в обидва боки: залишки, ціни, замовлення, статуси, відвантаження. Фіксуємо частоту обміну, первинне джерело за кожним полем і правило розв'язання конфліктів.
- Налаштування обміну. Зіставляємо номенклатуру та склади, задаємо правила перерахунку цін, обробку часткових відвантажень і скасувань. Усе, що можна перевірити до запуску, перевіряється тут.
- Тестова експлуатація. Проганяємо обмін на живих замовленнях малим обсягом: звіряємо залишки, статуси й документи відвантаження, розбираємо кожне розходження до нуля.
- Відмовостійкість. Ставимо чергу повідомлень, журнал операцій, автоматичні повтори при недоступності зовнішньої сторони й повідомлення відповідального про збій.
- Передача рішення. Віддаємо документацію за потоками, регламенти ручних операцій, доступи й навчання співробітників. Далі — супровід і доопрацювання, коли майданчик змінює правила.
На момент увімкнення обміну в робочому режимі команда вже бачить, як система поводиться на реальних замовленнях, і знає порядок дій при збої.
Схема обміну, мапінг полів і регламенти супроводу
Після запуску інтеграції інтернет-магазину з KazanExpress замовник отримує не «чорний ящик», а комплект документів, за яким обмін можна перевірити, передати іншому підряднику або пояснити новому співробітнику. Нижче — що саме залишається на руках.
- Схема потоків даних. Хто ініціатор обміну, які події йдуть у маркетплейс, що надходить назад, де стає черга і що відбувається, якщо одна зі сторін недоступна.
- Таблиця зіставлення полів і статусів. Артикул, найменування, ціна, залишок, номер замовлення, його стан — як поле облікової системи перетворюється на поле маркетплейсу й навпаки.
- Правила обробки помилок. Для кожної типової помилки — причина, реакція системи (повтор, відкладене відправлення, повідомлення) і межа спроб, після якої заявка йде людині.
- Інструкція для співробітників. Що робити оператору при розходженні залишків, завислому замовленні або відхиленій картці — з прикладами й порядком дій.
- Регламент супроводу. Періодичність перевірок, хто відповідає за оновлення довідників, як відстежується зростання відмов і коли підключається інженер.
- Журнал змін і тестові сценарії. Набір перевірок перед кожним оновленням та історія доопрацювань із зазначенням причини — щоб правки не ламали вже працюючий обмін.
Цього достатньо, щоб передати інтеграцію на підтримку без нас і не втратити контекст.
Кейс: підключення асортименту та синхронізація залишків
Клієнт — постачальник електроніки й аксесуарів: близько 4 800 позицій на складі та три майданчики продажів, включно з KazanExpress. Каталог вели вручну три людини — картки заводили копіюванням, залишки перераховували за таблицею раз на добу, ціни правили окремо на кожній вітрині.
До вечора розходження між складом і вітринами сягали 8–9%, замовлення на відсутній товар ішли в скасування, а реакція на нове замовлення займала 3–4 години.
Що змінили
Між обліковою системою та майданчиками поставили обмінний сервіс. Він забирає залишки з обліку, приводить їх до єдиного довідника за артикулом і штрихкодом і розкладає по вітринах.
Назовні йдуть лише зміни — дельти від минулого циклу, а не повне вивантаження каталогу; нічна звірка перераховує все цілком і закриває накопичені розходження.
Замовлення й статуси йдуть через чергу з повторами при збої: підтвердження, збирання, передача номера відправлення — без участі менеджера.
Метрики до і після
- Оновлення залишків: раз на добу → кожні 10 хвилин за дельтами.
- Розходження склад ↔ вітрина: 8–9% → 0,5%.
- Час реакції на замовлення: 3–4 години → близько 10 хвилин.
- Ручні операції з асортименту: близько 120 на день → 10 (лише нові картки).
- Скасування з причини «немає в наявності»: 6% замовлень → менш ніж 0,4%.
Підтримку ведемо за тим самим контуром: помилки обміну видно в журналі з прив'язкою до артикулу, операцію, що впала, можна повторити вручну або за розкладом. Новий майданчик підключається як ще один отримувач дельт — логіку обліку переписувати не доводиться.
Чим інтеграція KazanExpress відрізняється від ручного вивантаження
Ручне вивантаження — це файл, який оператор збирає й завантажує в кабінет продавця Магнит Маркет. Поки позицій небагато й ціни правляться рідко, схема працює. Розходження з'являється тоді, коли дані в обліковій системі змінюються частіше, ніж ви встигаєте перезібрати файл.
| Варіант роботи | Коли підходить | Обмеження |
|---|---|---|
| Ручне вивантаження файлом | Десятки позицій, рідкісні правки, один оператор | Дані застарівають між вивантаженнями — замовлення надходять на знятий товар |
| Обмін за розкладом | Сотні позицій, ціни та залишки змінюються кілька разів на день | Потрібні вивантаження з обліку й розбір помилок майданчика |
| Постійний обмін подіями | Тисячі позицій, кілька складів, промо та акції | Потрібні нормалізовані довідники й контроль черги замовлень |
| Обмін плюс ручні правки карток | Каталог зростає, контент доопрацьовує людина | Потрібне правило пріоритету над ручною правкою |
Поріг обсягу асортименту задає не розмір каталогу, а частота змін. Якщо залишок і ціна змінюються кілька разів на день, ручний режим перестає сходитися вже на кількох сотнях активних позицій: покупець оформлює замовлення на те, чого немає, а картка йде в блокування за скасування.
Трудовитрати на звірку зростають лінійно з асортиментом: кожен цикл — це звірка замовлень, статусів, повернень і залишків вручну. На невеликому каталозі це години на тиждень, на зростаючому — постійне навантаження, яке не масштабується разом із продажами.
Режим роботи обирають за трьома параметрами: частота зміни ціни та залишку, кількість складів, кількість замовлень на добу. За ними видно, де закінчується файл і починається постійний обмін — далі налаштовуємо розклад, обробку помилок і відкат партії.
Технічні питання щодо обміну з маркетплейсом
Перед стартом технічний керівник проганяє той самий список: чи спрацюється обмін з обліковою системою, що буде при обриві зв'язку, як вести кілька складів, що залишиться після передачі. Нижче — короткі відповіді.
Облікова система не віддає дані напряму — обмін усе одно можливий?
Так. Проміжний шар забирає вивантаження з бази або файлового сховища за розкладом і приводить його до структури, яку чекає майданчик. Номенклатуру зіставляємо за артикулом і штрихкодом, розходження йдуть у звіт, а не губляться мовчки.
Що станеться, якщо зв'язок із майданчиком зникне на годину?
Операції йдуть через чергу з повторними спробами, а кожній присвоюється ключ ідемпотентності — повтор не створює дубль замовлення або руху. Після відновлення зв'язку обмін наздоганяє накопичене, розходження звіряємо в журналі.
Як враховуються кілька складів і складні товарні групи?
Кожному складу відповідає свій ідентифікатор: залишок рахується окремо, пріоритет відвантаження задається правилом. Для комплектів і розмірних рядів ведемо зіставлення батьківських і дочірніх позицій, щоб варіант не перетворювався на окремий товар.
Що буде, якщо супроводжувати інтеграцію ми захочемо самі?
Передаємо конфігурацію обміну, схему потоків даних, правила зіставлення й опис черги повторів плюс інструкцію щодо типових збоїв. Розбір із вашою командою й супровід із нашого боку обговорюємо окремо.
Обговоримо ваше завдання і повернемося з оцінкою
Щоб оцінка була точною, а не «зі стелі», потрібні вихідні дані по магазину й поточній логіці роботи з майданчиком.
Інтеграція з KazanExpress / Магнит Маркет майже завжди впирається не в код, а в те, як у вас влаштовані каталог, залишки й обробка замовлень — тому починаємо з цього.
Що надсилати на старті:
- структуру товарних категорій і атрибутів — за нею будується зіставлення карток між вашою обліковою системою та майданчиком;
- поточний спосіб вивантаження цін і залишків (файл, таблиця, облікова система) і те, як часто дані мають оновлюватися;
- перелік схем відвантаження, з якими працюєте, і правила розподілу замовлень між складами;
- опис процесу обробки замовлення: хто підтверджує, хто друкує документи, у який момент ставиться статус;
- відомості про повернення та причини скасувань — вони задають правила зворотного запису в облік;
- контакти людей, які ухвалюють рішення щодо асортименту й логістики.
Оцінка надходить не однією цифрою, а планом робіт: етапи, що робимо на кожному, які дані потрібні від вас і коли, що вважається результатом етапу. Окремо показуємо приймання — на яких сценаріях перевіряємо обмін замовленнями та залишками і що робимо при розходженні.
Перший крок — розбір завдання: дивимося вступні, уточнюємо спірні місця щодо статусів і залишків, повертаємося з оцінкою, планом і термінами. Опишіть завдання у зручній формі — далі йдемо за узгодженим планом.
