Ти продаєш на Allegro і одночасно ведеш власний інтернет-магазин? Ти ризикуєш ситуацією, коли один і той самий товар купується двічі — на обох платформах практично в одну хвилину. Результат — скасований замовлення, незадоволений клієнт і потенційне зниження твоєї оцінки продавця. У цій статті ти дізнаєшся, як побудувати єдине джерело правди про стан складу та синхронізувати продажі між каналами.
Ризикова хвилина: коли той самий товар купують у двох каналах одночасно
Уяви ситуацію: клієнт на Allegro купує останню одиницю товару, а в цей самий момент інший клієнт оформлює замовлення на твоєму сайті. Система не бачить, що товар щойно був проданий в іншому місці. Обидві транзакції проходять, і тобі доводиться скасовувати одне. Клієнт, який отримав інформацію про відсутність товару після оплати, залишає негативний відгук. Це не теорія — ризик з'являється завжди, коли ти ведеш продажі більш ніж в одному каналі без автоматичної синхронізації залишків.
Чому це відбувається? Тому що ручне оновлення залишків не встигає за темпом продажів. Протягом хвилини може статися кілька транзакцій на різних платформах. Без системи, яка бачить кожен продаж як подію і миттєво реагує, подвійний продаж — питання часу, не вдачі.
Вартість відсутності синхронізації
Кожне скасоване замовлення — це не лише втрачений продаж. Це ще час на обробку скарг, негативний відгук на Allegro, потенційна втрата позиції в результатах пошуку та довіри майбутніх клієнтів. За місяць, при десятках таких ситуацій, витрати зростають багатократно.
Єдина правда про склад — центральне джерело залишків
Рішення починається з архітектури даних. Замість того, щоб підтримувати окремі залишки на Allegro, в інтернет-магазині та в таблиці, тобі потрібне єдине джерело правди. Всі канали продажів повинні читати залишок з одного місця і лише повідомляти про події — продаж, повернення, коригування.
Де це місце може знаходитися? Залежить від твоєї інфраструктури:
- CRM або ERP-система — якщо ти вже її використовуєш, склад повинен бути там, а Allegro і магазин лише читають і повідомляють про зміни.
- База даних — просте рішення, де одна таблиця зберігає поточні залишки, а API або автоматизація оновлює платформи.
- Таблиця — для малого масштабу, але вимагає ручної обробки і не підходить для тисяч товарів.
Ключовий принцип: склад — це джерело, канали продажів — лише споживачі і виробники подій. Ніхто не вводить вручну залишок «10 штук» — кожна зміна стає подією: продаж, прийом товару, коригування інвентаризації.
Що пропонує Allegro: журнал подій та масова зміна залишків
Allegro надає потужне API, яке дозволяє не лише читати і змінювати пропозиції, а й відстежувати всі зміни в них. Через endpoint GET /sale/offer-events ти можеш отримати історію подій, що стосуються твоїх пропозицій. Система повертає, серед іншого:
- OFFER_STOCK_CHANGED — зміна кількості одиниць у пропозиції, повертається також після покупки. Це ключова подія дозволяє визначити, що хтось купив товар.
- OFFER_PRICE_CHANGED — зміна ціни, корисно для відстеження знижок та акцій.
- OFFER_ENDED — завершення пропозиції, наприклад коли товар був проданий вручну.
Події можна фільтрувати за типом і датою. Завдяки цьому твоя система може реагувати на кожну зміну практично в реальному часі, а не чекати періодичної перевірки.
Allegro також пропонує можливість масової зміни ціни та кількості в багатьох пропозиціях одночасно. Якщо у тебе сотні товарів і ти хочеш оновити їх залишки після інвентаризації або імпорту від постачальника, тобі не потрібно робити це по одному.
Як це працює на практиці
Налаштовуєш автоматизацію, яка з регулярними інтервалами (або в реальному часі через веб-хуки, якщо Allegro їх надає) отримує події типу OFFER_STOCK_CHANGED. Коли система виявляє, що залишок зменшився, вона відправляє цю інформацію в твій центральний склад. Той, своєю чергою, оновлює залишки в інтернет-магазині та інших каналах.
Замовлення Allegro: коли товару справді немає
Одна зміна залишку в пропозиції — це не кінець історії. Не менш важливо відстежувати замовлення та їх статуси. Endpoint GET /order/events повертає всі події, пов'язані із замовленнями: покупка, заповнення форми доставки, скасування оплати та багато іншого.
Найважливіший статус — READY_FOR_PROCESSING. Він означає, що клієнт заповнив форму варіантів доставки і завершив оплату (або обрав оплату при отриманні або самовивік). Тільки в цей момент замовлення переходить в обробку, і ти можеш фізично зарезервувати товар. Раніші статуси, такі як FILLED_IN (клієнт заповнив дані, але ще не оплатив), не повинні викликати резервування на складі.
Чому READY_FOR_PROCESSING такий важливий
Багато продавців помилково реагують на перший сигнал покупки — подію BUY. Однак клієнт може заповнити форму, а потім скасувати оплату або просто не завершити транзакцію. Тільки статус READY_FOR_PROCESSING означає, що транзакція дійсно підтверджена і товар повинен бути списаний зі складу.
Пам'ятай також, що для одного замовлення може з'явитися кілька подій. Ти можеш отримати кілька повідомлень READY_FOR_PROCESSING, якщо клієнт зробив кілька покупок. Тому завжди будуй свою логіку на ідентифікаторі замовлення в об'єкті checkoutForm.
Сторона магазину: статус Processing як сигнал до списання
У WooCommerce і більшості популярних платформ магазинів статус замовлення «Processing» означає, що оплата отримана, а залишок на складі вже зменшений — про це йдеться в документації WooCommerce. Це сигнал для власника або складу підготувати і відправити замовлення.
Статуси замовлень WooCommerce працюють так:
- Pending payment — замовлення оформлено, але ще не оплачено.
- Processing — оплата отримана, залишок зменшено, замовлення очікує виконання.
- Completed — замовлення виконано і відправлено.
- Refunded — повністю повернено адміністратором.
Коли замовлення переходить в статус Processing, твоя система повинна створити подію списання в центральному складі. Ця подія автоматично оновлює залишки в Allegro та інших каналах. Завдяки цьому кожний наступний клієнт, незалежно від того, купує він через Allegro чи через твій магазин, бачить актуальний залишок.
З'єднання каналів: подія — спільна мова
Принцип простий: незалежно від того, де відбувся продаж, створюється одна подія списання залишку складу. Коли клієнт купує на Allegro, система фіксує покупку через OFFER_STOCK_CHANGED і зменшує залишок в центральному складі. Коли клієнт оплачує в інтернет-магазині, статус Processing в WooCommerce генерує ту ж подію списання. Обидва шляхи ведуть до одного центру управління залишками і оновлюють другий канал протягом секунд.
Частота оновлення: чому раз на добу недостатньо
Багато власників магазинів думають: «буду оновлювати залишки раз на день, вранці, перед роботою». Цей підхід працює, поки у тебе великі запаси і рідкісні транзакції. Проблема з'являється при останніх одиницях товару, які купуються часто і швидко.
Уяви товар, якого залишилося всього п'ять штук. Протягом години може статися шість транзакцій на Allegro і в магазині. Якщо ти оновлюєш залишки раз на день, остання з цих транзакцій закінчиться скасуванням. Клієнт отримає інформацію «вибачте, товар недоступний» після того, як вже оплатив.
Рішення цієї проблеми два:
- Оновлення практично в реальному часі — кожного разу, коли з'являється нова подія, ти миттєво оновлюєш залишки в усіх каналах.
- Буфер безпеки — для популярних товарів ти підтримуєш додатковий запас (наприклад, 2-3 одиниці), який не видний у продажу. Коли видимий залишок досягає нуля, товар автоматично зникає з продажу в усіх каналах.
Буфер — це бізнес-рішення, яке ти приймаєш сам: скільки ти готовий втратити потенційних клієнтів через недоступність, versus скільки можеш втратити через скасовані замовлення.
Таблиця подій: від джерела до місця призначення
Наступна таблиця показує типові події та потік інформації між системами:
| Подія | Джерело | Що змінюється | Куди відправляти |
|---|---|---|---|
| OFFER_STOCK_CHANGED | Allegro API | Залишок зменшено після покупки | Центральний склад → магазин |
| Замовлення оплачено (Processing) | Інтернет-магазин | Залишок зменшено | Центральний склад → Allegro |
| Повернення | Будь-який канал | Залишок збільшено | Центральний склад → усі канали |
| Коригування інвентаризації | Вручну / таблиця | Залишок змінено | Центральний склад → усі канали |
| OFFER_ENDED | Allegro API | Пропозицію завершено | Опціонально: сповіщення |
Таблиця допомагає побачити, що незалежно від джерела події, потік завжди однаковий: джерело генерує подію, центральний склад обробляє її, усі канали отримують оновлений залишок.
Зроби сам: ручний контроль та прості захисти
Якщо ти ще не маєш інтегрованої системи, ти можеш ввести прості захисти, які зменшать ризик подвійного продажу:
- Визнач товари з низьким залишком — раз або двічі на день перевіряй товари, яких залишилося 1-3 штуки. Якщо ти бачиш, що такий товар нещодавно купувався, тимчасово вимкни його в одному з каналів.
- Вимкни дублікати пропозицій — на Allegro виставляй лише одну пропозицію на товар. Не створюй багато варіантів з одним і тим самим товаром, бо це ускладнює відстеження залишків.
- Веди журнал скасувань — записуй кожну ситуацію, коли тобі довелося скасувати замовлення через відсутність товару. Через місяць ти побачиш масштаб проблеми і легше оціниш, наскільки автоматизація важлива для твого бізнесу.
- Встанови сповіщення — перевір, чи можна у твоїй платформі магазину увімкнути сповіщення про низький залишок, і встанови поріг 1–3 штуки.
Ці дії не вирішать проблему на сто відсотків, але дадуть тобі час і інформацію, необхідні для прийняття рішення про повну автоматизацію.
Як це виглядає з системою — автоматична синхронізація
Коли ти з'єднаєш канали продажів з центральною системою управління складом, весь процес виглядає так:
- 01Замовлення в каналі
- →02подія
- →03центральний склад
- →04оновлення в інших каналах
- →05робота
- →06звіт
Це означає, що коли клієнт купує товар на Allegro, твій інтернет-магазин протягом секунд побачить зменшений залишок і покаже «остання штука» або «недоступний». І навпаки: покупка в магазині миттєво оновить залишок на Allegro.
Система не дає гарантії нуля скасувань — все ще можуть траплятися прикордонні ситуації, наприклад коли клієнт купує в ту саму мілісекунду в двох каналах. Але вона значно зменшує ризик і усуває переважну більшість таких випадків.
Дізнайся, як Aura обробляє інтеграцію Allegro з інтернет-магазином та автоматичну синхронізацію залишків: Інтеграції, Інтернет-магазини, API, Адмін-панелі, Дашборди.
Прочитай також, чому варто думати про автоматизацію процесів у компанії та коли готове рішення SaaS працює краще, ніж власна інтеграція: Автоматизація процесів у компанії, Власна автоматизація чи готовий SaaS, n8n чи Make: вартість сценарію, CRM чи ERP: який рівень додати, Онлайн-замовлення для ресторану.
Часті питання
Чи потрібно мені використовувати API Allegro для синхронізації залишків?
Не обов'язково, але без API ти обмежений ручними методами. Ти можеш експортувати залишки в таблицю і вручну оновлювати пропозиції, але це трудомістко і схильно до помилок. API дозволяє автоматизувати цей процес і реагувати на зміни практично в реальному часі.
Що робити, якщо клієнт купив на Allegro, але не оплатив?
У такому випадку статус замовлення залишається на етапі FILLED_IN і не переходить в READY_FOR_PROCESSING. Поки оплата не буде завершена, система не повинна резервувати товар на складі. Саме тому твоя логіка повинна базуватися на статусі READY_FOR_PROCESSING, а не лише на факті покупки.
Чи можна використовувати одне рішення для кількох облікових записів Allegro?
Так, за умови, що кожен обліковий запис має свої дані доступу до API. Твоя центральна система повинна підтримувати кілька з'єднань і розрізняти, з якого облікового запису надійшла подія. На практиці це означає, що кожен обліковий запис Allegro матиме свій токен OAuth.
Що робити, якщо товар має варіанти (розмір, колір)?
Варіанти в Allegro — це окремі пропозиції з власними залишками. Тобі потрібно зіставити їх з відповідними варіантами в твоїй системі складу. Якщо ти ведеш продаж з множиною варіантів, переконайся, що твоя інтеграція обробляє цю логіку — інакше ти можеш продати розмір M, коли на складі залишився лише L.
Як часто я повинен отримувати події від Allegro?
Оптимально — кожні кілька хвилин, а найкраще в реальному часі через веб-хуки (якщо Allegro їх надає). При великій кількості транзакцій частота раз на годину може бути недостатньою для товарів з низьким залишком. Для товарів з високим залишком достатньо рідше.
Чи можу я синхронізувати залишки без програміста?
Частково. Деякі платформи магазинів пропонують плагіни для інтеграції з Allegro, які працюють без написання коду. Однак передові сценарії, як обробка кількох облікових записів, нестандартні правила буфера або передова звітність, зазвичай вимагають індивідуального рішення.