Портал постачальників для інтернет-магазину: без Excel і пошти

Портал постачальників для інтернет-магазину прибирає менеджера з ланцюжка «постачальник надіслав Excel, менеджер звів файли, оновив 1С і сайт». Постачальник сам завантажує ціни, залишки й фото, бачить замовлення від магазину і підтверджує відвантаження. Після перевірки дані потрапляють в облікову систему та на вітрину без ручного копіювання. Типова картина в магазині з 30–80 постачальниками: щодня приходить 10–20 прайсів у різних форматах, частина зі зміненими колонками. Двоє менеджерів витрачають пів дня на зведення, а клієнти все одно замовляють товар, якого вже немає.

Чим портал постачальників для e-commerce відрізняється від корпоративного

Портали великих мереж і виробників побудовані навколо процедури допуску: реєстрація контрагента, перевірка документів, тендери, договори. Для інтернет-магазину головне інше: швидкість і точність даних. Якщо постачальник змінив закупівельну ціну зранку, а на сайті вона оновилася ввечері, ви або продаєте в мінус, або втрачаєте замовлення через завищену ціну. Тому кабінет постачальника в e-commerce оцінюють за трьома показниками: скільки хвилин минає від зміни у постачальника до сайту, яка частка позицій розпізнається автоматично і скільки замовлень припадає на товар, якого фактично немає. Документообіг і рейтинги постачальників можна додати пізніше. Не плутайте цей інструмент з кабінетом оптового покупця. Там клієнт оформлює замовлення у вас, а тут постачальник передає вам дані й виконує ваші замовлення. Логіку оптового кабінету ми окремо розбирали в статті про B2B-портал і оптовий кабінет. Навіть якщо обидва модулі працюють на одній платформі, права доступу й сценарії в них різні.

Портал чи автоімпорт прайсів: як вирішити

Автоімпорт працює так: система за розкладом забирає файл з пошти, FTP, посилання або API постачальника, розкладає колонки за збереженими правилами й оновлює ціни та залишки. Постачальник при цьому нічого не змінює у своїй роботі. Для багатьох магазинів цього достатньо: з нашого досвіду, автоматичний імпорт товарів з прайс-листів знімає більшу частину ручної роботи вже після кількох тижнів розробки. Портал потрібен тоді, коли обмін має йти в обидва боки або постачальники не можуть стабільно віддавати файл одного формату.

З нашого досвіду, найчастіше працює гібрид. Великі постачальники з нормальним API або фідом підключаються автоімпортом, а дрібні й середні, які живуть в Excel, отримують кабінет. Переводити в кабінет того, хто вже віддає якісний API, немає сенсу.

Мінімальні функції кабінету постачальника для старту

Перша версія має закрити щоденну рутину, а не всі можливі сценарії. Ось перелік, з якого ми зазвичай стартуємо:

1. Вхід і ролі. Постачальник бачить лише свої товари й замовлення. В одного постачальника може бути кілька користувачів: менеджер з цін і комірник, який підтверджує відвантаження.
2. Завантаження прайсу. Файл Excel або CSV; система запам'ятовує, яка колонка відповідає артикулу, ціні й залишку. Наступного разу постачальник просто завантажує файл. Окремі позиції можна редагувати вручну.
3. Залишки окремо від цін. Залишки змінюються у кілька разів частіше, тому їх оновлюють окремою дією або через API, не чіпаючи прайс.
4. Зіставлення артикулів. Код постачальника прив'язується до вашого товару. Нерозпізнані позиції потрапляють у чергу, де менеджер прив'язує їх один раз.
5. Контент через модерацію. Фото, характеристики й описи новинок з'являються на сайті лише після перевірки контент-менеджером.
6. Замовлення постачальнику. Список замовлень зі статусами, повне або часткове підтвердження, відмова з причиною, введення номера ТТН.
7. Журнал змін і помилок. Постачальник бачить, що файл прийнято, які рядки відхилено і чому.
8. Сповіщення. Email або Telegram про нове замовлення і про помилки в прайсі.

На другий етап відкладаємо акти звірки й документообіг, аналітику продажів для постачальника, рейтинги, внутрішній чат і тендери. Без них портал уже економить час менеджерів.

Обмін даними з постачальниками та інтеграція з 1С/ERP

Перед розробкою треба вирішити, яка система головна для кожного типу даних. Робоча схема для більшості магазинів така: 1С або ERP зберігає номенклатуру, закупівельні ціни й облік, портал приймає дані від постачальника, а сайт отримує роздрібну ціну, розраховану за вашими правилами націнки. Дані постачальника не варто писати напряму в облікову систему. Між порталом і 1С потрібен проміжний буфер, де відбувається перевірка:

• ціна змінилася більше ніж на заданий відсоток, наприклад 15%: позиція чекає ручного підтвердження;
• залишок нижче порогу безпеки: на сайті показуємо «під замовлення» або 0, щоб не продати останню одиницю, яку постачальник уже віддав іншому;
• порожня ціна, нуль, текст замість числа: рядок відхиляється, постачальник бачить помилку;
• кожен пакет має статус «прийнято», «з помилками», «застосовано», бо надісланий файл ще не означає записані дані.

Частота оновлення залежить від ніші. Залишки зазвичай синхронізуємо кожні 15–60 хвилин, ціни раз або двічі на добу. Детальніше про налаштування обміну товарами, цінами й замовленнями ми писали в матеріалі про інтеграцію 1С з сайтом. Такий підхід з єдиною точкою контролю даних особливо корисний магазинам, які працюють одночасно з роздробом і оптом. Наприклад, TradeAuto на Laravel ми будували саме під роздрібні та оптові продажі. Портал постачальників у такій архітектурі стає ще одним джерелом даних, яке проходить через ту саму перевірку.

Замовлення постачальникам і дропшипінг: автоматизація закупівель

Друга частина цінності порталу полягає у зворотному потоці. Коли покупець оформлює замовлення на сайті, система сама визначає постачальника за наявністю, пріоритетом або закупівельною ціною і створює для нього замовлення в кабінеті. Далі логіка така:

1. Постачальник отримує сповіщення і має, наприклад, 2 години робочого часу на підтвердження.
2. Якщо підтвердив, замовлення йде у відвантаження. Якщо відмовив або не відповів, система пропонує наступного постачальника або передає задачу менеджеру.
3. Постачальник вводить номер ТТН, статус оновлюється в CRM і на сайті, клієнт отримує сповіщення.

Для дропшипінгу це критично: постачальник відправляє посилку напряму покупцеві, і без порталу ви дізнаєтеся про проблему лише тоді, коли клієнт зателефонує. Для моделі зі своїм складом портал формує замовлення на поповнення за мінімальними залишками, а закупівельник лише перевіряє та погоджує список. Такі сценарії зазвичай будують разом з обробкою замовлень і доставкою, а не окремо. Ми робимо це в межах послуги автоматизації інтернет-магазинів, щоб замовлення, закупівля і доставка працювали як один процес.

Де допомагає штучний інтелект

AI не замінює портал, але знімає найнуднішу частину роботи. На практиці він корисний у чотирьох місцях: розпізнає прайси, які приходять у PDF або навіть фото; зіставляє назви, коли одна й та сама модель у трьох постачальників записана по-різному; приводить характеристики до єдиного формату; готує чернетки описів новинок. Останнє слово лишається за людиною на модерації. Як ми вбудовуємо такі моделі в процеси магазину, описано на сторінці про розробку з AI.

Пілот з 2–3 постачальниками: етапи і терміни

Підключати всіх одразу не варто. Для пілоту візьміть трьох різних постачальників: великого зі стабільним фідом або API, середнього, який працює в Excel, і одного «проблемного», з яким найбільше ручної роботи. Так ви перевірите всі типові сценарії.

1. Аудит процесу, 1–2 тижні. Збираємо реальні прайси за місяць, описуємо, хто і що робить руками, заміряємо час менеджерів.
2. Правила і прототип, 1–2 тижні. Узгоджуємо схему даних, правила націнки, пороги контролю, екрани кабінету.
3. Розробка першої версії, 4–8 тижнів. Термін залежить від стану 1С і кількості сценаріїв.
4. Пілот, 3–4 тижні. Портал працює паралельно зі старим процесом, щоб порівняти дані й не зірвати продажі.
5. Масштабування. Підключаємо решту постачальників хвилями по 5–10, а не всіх в один день.

Що міряти під час пілоту: час від зміни у постачальника до сайту, частку нерозпізнаних позицій, кількість скасованих замовлень через відсутність товару, години менеджерів на тиждень і середній час підтвердження замовлення постачальником. Окремо подбайте про самих постачальників. Інструкція на одну сторінку і відео на 5 хвилин знімають більшість питань. Обов'язок оновлювати залишки через кабінет у визначені терміни краще закріпити в договорі поставки.

Скільки коштує портал постачальників

Цифри нижче орієнтовні, з нашої практики. Фінальна вартість залежить від стану 1С або ERP, кількості форматів даних, наявності дропшипінгу і від того, чи будуємо модуль у наявний магазин, чи окремий сервіс.

Окупність порахувати просто. Якщо два менеджери щодня витрачають по 3 години на зведення прайсів і листування з постачальниками, це близько 130 годин на місяць. Додайте скасовані замовлення через неактуальні залишки й продажі в мінус після зміни закупівельних цін. З нашого досвіду, у магазинах з десятками постачальників перша версія порталу зазвичай окупається протягом року, але точний строк залежить від обсягу замовлень і маржі.

Помилки, через які портал не запрацює

• Постачальників ніхто не мотивував. Якщо кабінет для них лише додаткова робота, вони продовжать надсилати Excel на пошту. Покажіть вигоду: швидше підтвердження замовлень, менше дзвінків, прозорі статуси.
• Старт з усього одразу. Документообіг, рейтинги й аналітика в першій версії розтягують запуск на пів року.
• Немає відповідального за дані. Хтось у вашій команді має розбирати чергу нерозпізнаних позицій і модерацію, інакше вона накопичується.
• Запис напряму в 1С. Одна помилка в прайсі без буфера і контролю перезаписує ціни на сотні товарів.
• Ігнорування змін у файлах. Постачальник додав колонку, і імпорт мовчки зламався. Потрібні сповіщення про зміну структури файлу.

Часті запитання

Чим власний портал відрізняється від кабінету продавця на маркетплейсі?

Кабінет на маркетплейсі на кшталт Rozetka працює за правилами майданчика і лише для його асортименту. Власний портал налаштовується під ваші процеси: ваші правила націнки, вашу 1С, ваших постачальників і ваш сценарій відвантаження, включно з дропшипінгом.

Що робити, якщо постачальник відмовляється працювати в кабінеті?

Підключіть його автоімпортом: система сама забиратиме його файл з пошти або за посиланням. Портал і автоімпорт можуть працювати паралельно, і дані з обох джерел проходять ту саму перевірку.

На якій платформі будувати портал постачальників?

Ми зазвичай робимо його окремим сервісом на Laravel або Nest.js, який обмінюється даними з магазином на WooCommerce, OpenCart, Magento чи кастомній платформі та з 1С. Так портал не навантажує вітрину, і його можна розвивати незалежно.

Чи можна почати з автоімпорту, а портал додати пізніше?

Так, і часто це найрозумніший шлях. Правила зіставлення артикулів і перевірки даних, налаштовані для автоімпорту, згодом переходять у портал без переробки. Якщо закупівлі у вашому магазині досі тримаються на пошті й Excel, команда Kliox може розібрати ваш процес і чесно сказати, що дасть результат швидше: автоімпорт, портал чи їхнє поєднання. Почати можна з короткої розмови про ваших постачальників і облік.