Знакомая ситуация: у вас 10, 20, а то и 50 поставщиков и каждый присылает данные так, как ему удобно, а не так, как удобно вам. Один скидывает Excel-файл в почту раз в неделю, другой отдает выгрузку по API, третий вообще присылает ссылку на XML, который нужно скачивать руками каждое утро. В итоге менеджер по закупкам превращается в оператора CTRL+C / CTRL+V, тратя половину рабочего дня на то, чтобы просто свести цифры в одну таблицу. И это ещё до того, как начинается работа с ассортиментом, ценами и остатками.
Пока данные собираются вручную, магазин теряет деньги: товар продается по старой цене, хотя поставщик её поднял ещё вчера, позиция висит на сайте «в наличии», хотя склад пуст уже неделю, новинка, которая могла принести хорошую маржу, тонет в тысячах строк обновления и остается незамеченной. Учет товаров по поставщикам — это не бухгалтерская формальность, а фундамент, на котором держится весь интернет-магазин с мульти-вендорной моделью закупок. Кстати, если вы работаете по модели дропшиппинга, эта проблема встает ещё острее — там от актуальности остатков зависит буквально каждый заказ.
Главные проблемы разрозненных баз поставщиков
Прежде чем говорить про решение, нужно честно разобрать, откуда растут корни хаоса. Проблема не в лени менеджеров и не в плохом Excel, она системная, и без понимания её природы любая попытка «просто навести порядок руками» обречена на провал.
Зоопарк форматов CSV, XML, JSON, YML
Первая и самая очевидная боль — у каждого поставщика свой формат выгрузки. Кто-то живет в 1990-х и присылает CSV с кириллицей в неправильной кодировке. Кто-то генерирует YML специально под маркетплейсы. Крупные дистрибьюторы отдают JSON через API, а мелкие оптовики до сих пор скидывают банальный Excel-файл, в котором вперемешку лежат логотип компании, шапка с контактами и сам прайс где-то с 15-й строки.
Логичный вопрос — а почему не заставить всех поставщиков присылать данные в одном виде? Ответ прост — вы не единственный клиент поставщика. У него могут быть сотни таких же закупщиков, и перестраивать выгрузку под каждого из них экономически бессмысленно. Более того, крупные поставщики скорее откажутся от сотрудничества с мелким магазином, чем изменят свою внутреннюю систему учета под чужие требования. Значит, адаптироваться должны вы, а точнее ваша система учета поставок товара.
Конфликты цен и дубли карточек
Вторая проблема — это столкновение интересов внутри вашей собственной базы. Представьте ситуацию — Поставщик А продает смартфон за 25 000 рублей и у него на складе 12 штук. Поставщик Б продает точно такую же модель за 24 300 рублей, но остаток у него всего 3 штуки. Возникает целая цепочка вопросов:
- Какую цену показывать на витрине — минимальную, среднюю или ту, что выгоднее по марже?
- Как считать общий остаток — суммировать 12 и 3, или показывать данные только от одного поставщика?
- Что делать, если у одного из них товар закончился, а у второго ещё есть — нужно ли моментально переключаться на второй источник?
- Как понять, что это вообще один и тот же товар, если у поставщиков разные артикулы и слегка отличается название?
Без четких правил приоритета менеджер решает эти вопросы вручную каждый раз, когда обновляется прайс. А если прайсы обновляются ежедневно у десятка поставщиков — это уже не работа, а конвейер ошибок, который напрямую бьет по юнит-экономике магазина — вы либо теряете маржу, продавая по невыгодной цене, либо теряете клиентов, показывая неактуальные остатки.
Скрытые новинки
Третья беда — потеря новых позиций. Поставщик присылает обновленный прайс на 40 000 строк. Из них 39 850 — это товары, которые уже есть в вашем каталоге, просто с новой ценой или остатком. А 150 строк — это совершенно новые модели, которые только появились на складе и могут стать вашим следующим хитом продаж. Найти эти 150 строк вручную в общем массиве данных практически нереально. В итоге магазин узнает о новинке через месяц, когда конкуренты уже расхватали первую партию клиентов и заняли верхние позиции в выдаче маркетплейса.
Как правильно организовать учет поставок товара и прайс-листов
Прежде чем переходить к автоматизации, важно выстроить логику процесса. Даже самая мощная система не поможет, если на входе царит хаос в мышлении — сначала нужно продумать архитектуру, а потом её внедрять.
Шаг 1. Единая точка входа
Первое, что нужно сделать — полностью отказаться от практики скачивания файлов на рабочий стол сотрудника. Это узкое горлышко всей системы. Если Мария из отдела закупок в отпуске или уволилась, а пароль к почте поставщика знала только она — обновление прайса встает.
Правильный подход — настроить автоматический забор данных напрямую из источника:
- по прямой ссылке на файл, который поставщик обновляет на своем сервере;
- через FTP-доступ, если поставщик выгружает данные на защищенный сервер;
- через API, когда система сама стучится к поставщику и забирает актуальные данные без участия человека;
- парсингом сайта, если у поставщика вообще нет нормальной выгрузки, а есть только каталог на сайте. Подробнее о том, как устроен этот процесс, мы разбирали в статье про парсинг каталогов поставщиков и цен конкурентов.
Как только все источники подключены в одну точку, у вас появляется реальная база учета товаров, а не хаотичная папка с файлами вида «прайс_финал_2.xlsx».
Шаг 2. Настройка правил приоритета
Второй шаг — прописать логику, по которой система будет сама принимать решения в спорных ситуациях, описанных выше. Это делается один раз, но экономит десятки часов в месяц. Нужно определить:
- По какому полю сопоставлять товары от разных поставщиков — по артикулу, штрихкоду или по совпадению названия и характеристик.
- Какую цену выводить на витрину, если товар есть у нескольких поставщиков — минимальную, для конкурентности, или ту, что дает максимальную маржу при текущем спросе.
- Как агрегировать остатки — суммировать по всем поставщикам или показывать данные только от приоритетного источника.
- Что происходит, если приоритетный поставщик обнулил остаток — переключается ли карточка автоматически на резервного поставщика без участия человека.
Когда эти правила формализованы, учет поступления товара превращается из ручного разбора в предсказуемый процесс, который работает по алгоритму, а не по настроению менеджера в конкретный день.
База учета товаров нового поколения — PIM вместо таблиц
Все описанные шаги можно реализовать вручную через связку Excel и Google Таблиц, но это работает только пока у вас 2-3 поставщика и пара сотен товаров. Как только счет идет на десятки прайсов и десятки тысяч позиций, ручная схема физически не выдерживает нагрузки. Здесь на сцену выходит PIM-платформа — специализированный инструмент, заточенный именно под эту задачу, и наша PIM-платформа StartCommerce закрывает все болевые точки, описанные выше, буквально из коробки.
Начнем с формата. StartCommerce принимает прайсы вообще в любом виде — Excel, CSV, XML, YML, JSON, забирает данные по ссылкам, через FTP и API, а также умеет парсить сайты поставщиков, у которых нет нормальной выгрузки вообще. Вам больше не нужно ничего «заставлять» поставщика делать по-другому — система сама подстраивается под его формат.
Дальше решается проблема кривых данных. Если поставщик вставил в Excel логотип компании и все колонки съехали на пару строк вниз — обычная выгрузка просто ломается и падает с ошибкой. StartCommerce устроен иначе — алгоритм сканирует до 50 строк вниз, находит реальные заголовки таблицы и корректно распознает структуру, независимо от того, сколько мусора добавил поставщик. Колонки связываются визуально — вы один раз указываете, где артикул, где цена, где остаток, и система запоминает эту связь навсегда и в зависимости от того меняется прайс, добавляются в него новые строкии или колонки система пмнит связку и если в целом связаные колонки остаются в прайс листе после его измнения, система новые координаты автоматически запоминает.
Отдельная головная боль многих закупщиков — отсутствие артикулов у части товаров. Бывает, что поставщик присылает позиции без внутреннего кода вообще, полагаясь только на название. StartCommerce решает это автогенерацией — если артикула нет, система создает уникальный хэш-идентификатор автоматически из свойства колонки которое вы укажите главное чтобы оно было надлежное и не менялось, названия товара тут более менее подходит, и товар не теряется, не задваивается и корректно участвует в дальнейшей обработке.
Теперь про самую болезненную часть — конфликты между поставщиками одного и того же товара. У StartCommerce есть умный маппинг дубликатов — если три разных поставщика продают одинаковую позицию, либо вы вручную либо с помошью нашей системы автоматически объединяет их в одну карточку товара. При этом вы сами задаете правило — выбирать минимальную цену для конкурентности на рынке или максимальную для лучшей маржи, а остатки при этом суммируются автоматически по всем источникам. Это именно та логика приоритетов, которую раньше приходилось прописывать и поддерживать вручную.
Что касается скорости — здесь работает механизм дельта-обновлений. Когда поставщик меняет прайс по ссылке, StartCommerce не перекачивает и не пересчитывает весь файл заново. Система за секунды находит именно те строки, которые изменились, и обновляет только их — конкретные цены и остатки. Мы подробно разбирали механику этого процесса в статье про автоматическое обновление остатков в интернет-магазине. Это критически важно для защиты от штрафов маркетплейсов за продажу товара, которого физически уже нет на складе — «воздуха», как это называют сами селлеры.
Дополнительный бонус — встроенные нейросети. Мало просто собрать данные от поставщика, их еще нужно привести к товарному виду для продажи. ИИ внутри StartCommerce чистит откровенно рекламный или неряшливый текст, генерирует SEO-описания для карточек товаров и улучшает качество мыльных фотографий, которые чаще всего присылают именно мелкие и средние оптовики. Как именно это работает и почему уникальные описания критически важны для ранжирования — читайте в статье про уникальные описания товаров и работу ИИ с хаосом прайс-листов.
А что происходит с готовыми данными дальше? Из PIM выгрузка идет напрямую в нужном виде — есть готовые шаблоны под популярные CMS и маркетплейсы, а если площадка требует индивидуальный пустой шаблон — система сгенерирует файл именно под её структуру. Схема получается такая:
- вы один раз настраиваете источники и связи между колонками для каждого поставщика;
- система переваривает любой формат и любой уровень «грязи» в данных;
- дубликаты объединяются автоматически по заданным правилам приоритета;
- на выходе получается чистый, готовый к загрузке каталог для вашей витрины или маркетплейса.
Именно так должна выглядеть современная база учета товаров — не бесконечная ручная сверка таблиц, а один раз настроенный конвейер, который дальше работает сам, независимо от того, сколько новых поставщиков вы подключите. Это особенно важно, если вы задумываетесь о развитии собственных каналов продаж — подробнее о том, зачем это нужно, можно почитать в материалах про трафик без Wildberries и Ozon и жизнь после маркетплейсов.
Заключение
Хаос в прайсах поставщиков — это не приговор и не неизбежная плата за работу с мульти-вендорной моделью. Это просто задача, которую можно и нужно решить один раз, а не разгребать заново каждый день руками. Правильно выстроенный учет товаров по поставщикам экономит десятки часов в месяц, убирает конфликты цен и защищает от продажи товара, которого уже нет на складе.
Не верьте на слово — проверьте на своих реальных данных. Загрузите в StartCommerce два самых кривых, самых проблемных прайса от ваших поставщиков, те, где съезжают колонки, нет артикулов и путаница с ценами. Посмотрите, как система сведет их за несколько минут и выдаст готовый файл, который можно сразу загружать в любую CMS или на любой маркетплейс.
