Для продавца SKU — не просто код в таблице. Это точка, где сходятся карточка товара, остатки, поставка, маркировка и документы. Если одна и та же модель появляется в нескольких вариантах, легко потерять связь между конкретным товаром и подтверждением его соответствия.
Тема сертификации здесь начинается не с загрузки файла на Wildberries, а с вопроса: что именно описывает документ и совпадает ли это с тем, что продавец отправляет покупателю. Ошибка может появиться не только в самом документе. Иногда проблема начинается раньше — при создании SKU, названии варианта или объединении товаров в одну карточку.
Почему SKU стоит считать единицей контроля
Для внутренней работы продавца удобно считать SKU отдельной контролируемой единицей товара. Это не обязательно означает, что для каждого цвета или размера нужен отдельный документ. Связь зависит от содержания документа, характеристик товара и того, как оформлена модель или линейка.
Предположим, у одной модели есть несколько цветов и размеров. Если материал, конструкция, назначение и другие значимые характеристики не меняются, продавец может рассматривать их как варианты одной группы для проверки документов. Но это только рабочая гипотеза. Нельзя автоматически переносить подтверждение с одной версии на другую, если меняется состав, устройство, производитель или иная характеристика, от которой зависит область действия документа.
Практический вывод простой: SKU нужно связывать не только с ценой и остатком, но и с записью о том, каким документом подтверждается именно этот вариант.
Где возникает разрыв между карточкой и документом
Наиболее уязвимое место — расхождение названий и характеристик. В карточке продавец указывает бытовое или маркетинговое название, а в документе может использоваться другое наименование модели. Само по себе различие слов не доказывает ошибку, но его нужно объяснить внутренней связкой: артикулом, моделью, производителем, составом или другим идентификатором, который действительно присутствует в документах.
Риск выше, если продавец:
- объединяет в одну карточку товары с разным составом или конструкцией;
- создаёт новый SKU после изменения характеристик, но оставляет старую запись о документе;
- переносит документ на похожий товар без проверки его области применения;
- хранит файл отдельно от данных о том, к каким SKU он относится;
- проверяет только наличие вложения, но не сверяет текст документа с карточкой и поставкой.
Это не утверждение о конкретной проверке или действующем требовании Wildberries. Это сценарии, в которых продавец сам создаёт слабое место в учёте. Даже без изменения правил площадки такая путаница усложняет ответы на вопросы о товаре и повышает риск ошибочной публикации документа.
Как разложить товар по группам до загрузки
Сначала составьте простую таблицу. В одной строке укажите SKU, название модели, вариант, состав или материал, производителя, поставщика, номер партии при наличии и документ, на который вы опираетесь. Отдельно добавьте поле «почему документ относится к этому SKU». Одной фразы достаточно, если она проверяема по самому документу.
Затем разделите товары на три группы:
- Совпадение. Наименование и ключевые характеристики SKU прямо соответствуют документу.
- Вариант модели. Отличается цвет, размер или другая характеристика, но продавец может показать, почему документ охватывает этот вариант.
- Нужна отдельная проверка. Изменились состав, конструкция, назначение, изготовитель или другие существенные данные.
Третью группу не стоит закрывать догадкой. Если из документа нельзя понять его границы, лучше временно пометить SKU как требующий уточнения и проверить вопрос до поставки или расширения ассортимента.
Что проверить в файле перед привязкой к SKU
Проверка должна отвечать не на вопрос «есть ли PDF», а на вопрос «можно ли связать этот файл с конкретным товаром». Сверьте название изделия, модель или серию, изготовителя, заявителя, вид документа, даты и другие поля, которые указаны в самом документе. Не добавляйте в карточку характеристику только потому, что она есть у похожего товара.
Если документ относится к партии, проверьте, совпадает ли поставщик и период поставки с вашей записью. Если он описывает серию или несколько моделей, сохраните у себя основание для такой связи. Это может быть перечень моделей в документе или другой явно указанный диапазон. Если диапазон не указан, не расширяйте его по аналогии.
Название файла тоже должно помогать работе. Например, внутренний формат может включать номер документа, модель и дату проверки. Это не заменяет содержание документа, но уменьшает риск прикрепить файл от другого SKU.
Как не перепутать изменение товара с новым вариантом
Для каждого изменения задайте один вопрос: покупатель получает тот же товар с небольшим отличием или уже другую модель по значимой характеристике? Если ответ неочевиден, не объединяйте SKU только ради удобства каталога.
Условный пример: продавец заменил материал изделия и оставил прежний артикул. Если документ описывает старый материал, связывать его с обновлённым товаром нельзя без отдельного подтверждения. Если же изменился только цвет, а документ прямо охватывает модель без разделения по цветам, связь может быть допустимой — но это нужно подтвердить текстом документа, а не предположением.
Минимальный порядок перед поставкой
- Зафиксировать список SKU и вариантов, которые реально отправляются.
- Сопоставить каждый SKU с моделью и характеристиками в документе.
- Отдельно отметить товары с изменённым составом, конструкцией или изготовителем.
- Проверить, что в карточке нет характеристик, которых нет у фактического товара.
- Сохранить версию документа и дату внутренней проверки.
- После изменения товара повторить сопоставление, а не копировать старую связь автоматически.
Моя оценка такова: продавцу выгоднее управлять не папкой документов, а картой связей «SKU — модель — вариант — документ — поставка». Такая карта не гарантирует принятие товара площадкой и не заменяет профильную проверку требований. Зато она показывает, где именно находится неопределённость, и не позволяет закрыть её одним похожим файлом.
Если правила Wildberries для конкретной категории, способа продажи или вида документа требуют отдельного действия, это нужно проверять по актуальной информации площадки и применимым требованиям. До такой проверки безопаснее не выдавать внутреннюю догадку за подтверждённое условие.