Майже кожен магазин, який працює з постачальниками, проходить один і той самий шлях: спершу ціни й залишки переносять у сайт руками, бо «постачальників усього три», потім це займає годину щодня, потім хтось помиляється на порядок у ціні — і тільки після цього починають думати про автоматизацію.
Проблема не в лінощах. Ручне перенесення прайсів має вбудовану ваду: воно робиться людиною наприкінці дня, по кількох файлах різної структури, з копіюванням між таблицями. Помилка тут не випадковість, а питання часу.
Чим це коштує насправді
Продаж того, чого немає. Найдорожча помилка: клієнт замовляє, оплачує, а товару в постачальника вже тиждень немає. Далі — вибачення, повернення грошей і зіпсована репутація. Ціна одного такого випадку значно вища за вартість автоматизації.
Продаж за старою ціною. Постачальник підняв ціну, на сайті лишилася стара — і кожне замовлення приносить збиток замість прибутку.
Товар, який ніхто не бачить. Позиція зʼявилася в прайсі, але на сайт її не завели, бо руки не дійшли. Вона просто не продається — без жодного сигналу про це.
Час, який не масштабується. Три постачальники — година на день. Десять — це вже окрема людина, яка нічого не заробляє, а тільки переносить цифри.
Що взагалі приходить від постачальників
Формати різні, і жоден постачальник не буде підлаштовуватися під вас.
Файл на пошту — Excel або CSV, раз на день чи раз на тиждень. Найпоширеніший варіант у малому бізнесі.
Посилання на файл — постійна адреса, за якою лежить свіжий прайс. Зручніше за пошту: файл можна забирати за розкладом.
XML-фід — структуроване вивантаження з залишками й цінами. Найзручніший варіант, часто той самий формат, що використовується для маркетплейсів — про нього в матеріалі про товарний фід.
API — прямий запит до системи постачальника, актуальні дані в момент запиту. Трапляється рідше, зазвичай у великих дистрибʼюторів. Що це означає простими словами — у матеріалі про API та інтеграції.
Практично завжди у вас буде суміш: один постачальник із нормальним XML, два — з файлами різної структури на пошту. І це нормально, бо всі вони зводяться до одного механізму.
Як влаштоване нормальне оновлення
Крок 1. Забір файлу за розкладом. Система сама щоночі забирає прайс із пошти або за посиланням. Ніхто нічого не пересилає й не завантажує.
Крок 2. Перетворення до єдиного вигляду. Для кожного постачальника один раз описується правило: де артикул, де ціна, де залишок, з якого рядка йдуть дані, у якій валюті ціна. Далі будь-який файл автоматично зводиться до однакової структури.
Крок 3. Звʼязування з товарами сайту. За артикулом постачальника, збереженим у картці. Не за назвою — назви розходяться завжди.
Крок 4. Застосування правил націнки. Ціна постачальника — це не ціна на сайті. Націнка задається правилами: відсоток за категорією, окремі значення для конкретних товарів, округлення до звичного вигляду. Логіка розрахунку — у матеріалі про ціноутворення в інтернет-магазині.
Крок 5. Оновлення залишків. Тут важливий момент: залишок постачальника рідко варто показувати як свій точний. Достатньо трьох станів — є, мало, немає. Як це поєднується з власним складом, описано в матеріалі про складський облік.
Крок 6. Звіт про те, що змінилося. Скільки товарів оновилося, скільки зникло з прайсу, скільки нових позицій зʼявилося, які рядки не вдалося розпізнати.
Запобіжники, без яких це небезпечно
Автоматичне оновлення без перевірок гірше за ручне: помилка розлітається по всьому каталогу за секунди.
- Ліміт на різку зміну ціни. Якщо ціна змінилася більш ніж удвічі — не застосовувати, а винести на перевірку. Це майже завжди зсув колонки у файлі, а не реальна зміна.
- Ліміт на масове обнулення залишків. Якщо в цьому прайсі раптом «немає» девʼяноста відсотків позицій — це збій вивантаження, а не порожній склад постачальника.
- Ніякого автоматичного видалення карток. Зникло з прайсу — статус «немає в наявності», сторінка лишається.
- Сигнал про тишу. Якщо прайс не прийшов у звичний час — це має бути окреме повідомлення. Мовчазний збій найнебезпечніший, бо сайт продовжує працювати зі старими даними й ніхто цього не помічає. Механіка описана в матеріалі про моніторинг інтеграцій.
З чого починати
Не з усіх постачальників одразу. Візьміть одного — того, чий прайс змінюється найчастіше або чиї товари дають найбільше замовлень. Налаштуйте на ньому весь ланцюжок, попрацюйте два тижні, зловіть перші несподіванки на реальних даних. Далі підключати наступних значно дешевше, бо механізм уже є — залишається описати правило перетворення для нового файлу. Загальний принцип вибору першого кроку — у матеріалі про те, з чого почати автоматизацію.
Коротко
Ручне перенесення прайсів ламається не через недбалість, а структурно: різні формати, кінець дня, копіювання між таблицями. Ціна помилки — продаж того, чого немає, і продаж за старою ціною. Нормальний механізм складається з шести кроків: забір файлу за розкладом, перетворення до єдиного вигляду за правилом для кожного постачальника, звʼязування за артикулом (не за назвою), правила націнки, оновлення залишків у трьох станах, звіт про зміни. Обовʼязкові запобіжники: ліміт на різку зміну ціни, ліміт на масове обнулення залишків, заборона автоматично видаляти картки й сигнал, коли прайс не прийшов узагалі. Починати з одного постачальника, а не з усіх одразу.
Ми в Obliko налаштовуємо такі інтеграції під конкретні формати ваших постачальників — щоб ціни й залишки на сайті оновлювалися самі, а увагу забирали тільки ті випадки, які справді її потребують.
Як часто треба оновлювати ціни постачальників?
Залежить від того, наскільки швидко вони змінюються. Для більшості товарних груп достатньо раз на добу вночі. Там, де ціна привʼязана до курсу або дефіцитного товару, — кілька разів на день. Головне не частота, а те, щоб оновлення відбувалося без участі людини: прайс, який оновлюють руками «коли дійдуть руки», завжди застаріває саме в той момент, коли це найдорожче.
Що робити, якщо постачальник надсилає прайс у незручному Excel?
Не просити його змінити формат — він цього не зробить. Робоче рішення — правило перетворення для кожного постачальника окремо: яка колонка є артикулом, яка ціною, яка залишком, з якого рядка починаються дані. Один раз описали — далі файл будь-якої структури автоматично зводиться до єдиного вигляду. Ламається це тільки тоді, коли постачальник змінює структуру файлу, і саме на це потрібна перевірка.
Як звʼязати товари постачальника з товарами на сайті?
Через артикул постачальника, збережений у картці товару окремим полем. Назва для цього не годиться: у постачальника вона своя, у вас — своя, і будь-яка правка назви розриває звʼязок. Якщо ви працюєте з кількома постачальниками одного товару, зберігайте артикул кожного — тоді система може брати ціну того, у кого зараз дешевше або хто має залишок.
Що робити з товарами, які зникли з прайсу?
Не видаляти автоматично. Зникнення з прайсу частіше означає тимчасову відсутність або збій вивантаження, ніж припинення постачання. Правильна поведінка — переводити такі товари в статус «немає в наявності» й лишати сторінку доступною. Автоматичне видалення карток — найшвидший спосіб втратити позиції в пошуку через помилку в чужому файлі.
Потрібен сайт або застосунок?
Розробляємо під ключ — від дизайну до запуску. Порахуємо ваш проєкт безкоштовно.