Одинаковый артикул в двух кабинетах может обозначать разные размеры, а разные артикулы — одну и ту же складскую позицию. Перед общим учётом нужен проверяемый ответ для каждой строки: какой вариант товара стоит за внешней карточкой, в какой единице он учитывается и кому принадлежит запас. Название и совпавший штрихкод помогают искать кандидатов, но не заменяют этот ответ.

Ниже — порядок очистки каталога с таблицами соответствий, очередью спорных строк и историей решений. Он подходит селлеру, который подключает второй кабинет, объединяет справочники или готовится к переезду WMS. Общая модель запаса разобрана в статье об остатках нескольких кабинетов; здесь результатом будет принятый словарь товаров, по которому можно проверить следующий импорт.

Ключ связи · учебный пример
Источник + кабинетОдинаковое число в двух кабинетах ещё не означает один товар.
Тип + значение IDERP: product_id 000012 и 000013 — две разные позиции, даже без variant_id.
Проверенный SKUВариант, владелец и единица подтверждены; спорная строка остаётся в очереди.
Связь строится по составному ключу. Артикулы 0012 и 12 сохраняются как разные строки; совпадение названия или штрихкода само по себе не разрешает объединение.

Рабочие таблицы: начните с одной товарной группы

Скачайте пустые таблицы и сравните их с заполненным примером. Шаблон не отправляет данные в систему и не выполняет массовое объединение.

Рабочий документ Пустой шаблон Учебный пример
Внешний вариант → складской SKU CSV соответствий Семь строк каталога
Неоднозначности и решения CSV очереди Три разбора
Изменения привязок CSV истории Два изменения

На узком экране таблицу можно прокрутить вправо. С клавиатуры: Tab до таблицы, затем стрелки.

Скачать инструкцию и словарь полей. Все данные в примере учебные; коды нельзя переносить в рабочие карточки или печатать на этикетках. Открытые спорные строки оставлены намеренно: хороший разбор сохраняет неизвестное до получения основания.

CSV импортируйте как текст. В Excel используйте «Данные → Из текста/CSV», укажите UTF-8 и запятую, затем задайте текстовый тип для идентификаторов, кодов и временных меток до загрузки. Проверьте пару 0012 и 12. Microsoft отдельно предупреждает, что обычное открытие CSV использует автоматическое распознавание типов; кавычки вокруг значения не гарантируют сохранение ведущих нулей. Инструкция Microsoft, проверена 31.10.2026.

Какие ключи сохранять

Сначала выгрузите каталог из каждого источника и сохраните неизменённую копию с датой, именем кабинета и числом строк. Для рабочего среза полезна контрольная сумма файла: она позволяет проверить, что обсуждается та же выгрузка. Исправления делайте в отдельной таблице.

Одна строка соответствия описывает один внешний вариант в конкретном источнике и кабинете. Если в источнике нет отдельного уровня вариантов и каждая позиция уже является самостоятельной единицей учёта, строка описывает такую позицию. Записывайте отдельно ключ карточки, ключ варианта, артикул продавца и штрихкоды. Поле с названием SKU в вашей ERP и поле sku площадки нельзя автоматически считать одним значением.

Данные Что сохранить Как использовать
Wildberries Кабинет, nmID, chrtID, vendorCode, коды из skus Различать карточку и размер; проверять конкретный внешний вариант
Ozon Кабинет, исходные product_id, sku, offer_id Хранить каждое поле в собственной колонке, без подмены названий
Складская система Её ID позиции, артикул, вариант, единица, владелец Выбрать принятый внутренний master_sku_id
Ключ соответствия key_kind и key_value Сохранить тип выбранного ключа: variant_id или product_id
Штрихкод Исходная строка, тип и происхождение, связь с вариантом Искать кандидатов и проверять сканирование
Версия среза Дата, файл/метод выгрузки, строка, версия соответствий Восстановить, откуда появилось решение

На узком экране таблицу можно прокрутить вправо. С клавиатуры: Tab до таблицы, затем стрелки.

В официальной статье WB nmID относится к карточке, chrtID — к размеру, vendorCode — к артикулу продавца, skus — к баркодам размера. На 31.10.2026 доступны индексированные фрагменты этой страницы; полный ответ документации получить не удалось. Перед автоматической загрузкой проверьте текущие поля своей выгрузки и конкретного метода. WB: карточка, группа и размер.

Ozon отдельно разъясняет: идентификаторы sku, product_id и offer_id сами по себе не определяют объединение товаров в мастер-карточку; оно связано с атрибутами товара. Поэтому общая витрина для покупателя ещё не означает одну складскую позицию. Ответ модератора Ozon, 28.03.2025, проверен 31.10.2026. В официальном примере Seller API от 19.10.2026 эти три поля также показаны раздельно; пример относится к песочнице Ozon Доставки, а не доказывает все сценарии продуктивного API. Источник.

Для собственного словаря используйте составной ключ «источник + кабинет + тип ключа + значение ключа». В колонку key_kind записывайте variant_id, а в key_value — source_variant_id. Для источника, в котором отдельного уровня вариантов действительно нет, используйте product_id и значение source_product_id. ID родительской карточки сохраняйте отдельно. Тип ключа обязателен: вариант 42 и позиция 42 не должны случайно считаться одной сущностью.

Если источник ведёт варианты, но их ID отсутствует в выгрузке, переводить строку на ключ родительской карточки нельзя: так разные размеры могут схлопнуться. Оставьте её в разборе и запросите полный срез. Пустое значение ключа также не объединяет несколько неизвестных строк. В учебной ERP отдельного уровня вариантов нет: позиции 000012 и 000013 имеют разные ключи даже при пустом source_variant_id.

Идентификатор, назначенный площадкой, полезен для отслеживания конкретной сущности; считать его вечным ключом товара после пересоздания или переноса карточки нельзя без проверки. Новый внешний ID сначала проходит обычное сопоставление.

Как принять соответствие

Ответственный за каталог проверяет четыре группы признаков: владельца, сам товар, значимые варианты и единицу продажи. Для футболки это модель, цвет, размер и количество в упаковке. Для другого ассортимента существенными могут быть объём, исполнение, совместимость или комплектность. Список признаков устанавливают до обработки спорных строк, иначе разные сотрудники будут применять разные правила.

Порядок работы:

  1. Найдите кандидатов по исходному коду или артикулу. Название используйте как дополнительную подсказку.
  2. Сверьте вариант с карточкой площадки и физической биркой либо документом поставщика. Для повторяющихся моделей одного названия мало.
  3. Подтвердите владельца и единицу. Одна штука и упаковка из двух штук должны оставаться различимыми.
  4. Запишите принятый складской SKU, основание, проверившего, версию и момент начала действия связи.
  5. Если существенный признак отсутствует или противоречит другому источнику, поставьте review и создайте строку в очереди. Пустой размер не означает «безразмерный».

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

Не удаляйте исходные пробелы, ведущие нули и похожие символы без сохранения оригинала. Для поиска можно добавить отдельное нормализованное значение, но артикулы 0012 и 12, латинская A и кириллическая А остаются разными исходными строками, пока их равенство не подтверждено. Нормализация должна помогать найти пару для проверки, а не принимать решение вместо неё.

Почему одинакового штрихкода бывает недостаточно

В системе GS1 разные размерно-цветовые варианты должны иметь собственные GTIN. Это полезное правило идентификации, но произвольная строка из выгрузки ещё не подтверждает корректный зарегистрированный GTIN и правильность наклеенной этикетки. GS1: размеры и цвета, обновлено 30.08.2024, проверено 31.10.2026.

Если один код обнаружен у M и L, остановите принятие этой связи. Возможны ошибка справочника, неправильная этикетка или смешение разных типов кода. Выберите основание, которое разрешит противоречие: исходную карточку размера, бирку физического товара, документ поставки. До результата спорный вариант не должен попадать в новое общее сопоставление. Действующие заказы по нему требуют отдельного разбора; файл очистки не является командой автоматически обнулить продажу.

Одинаковый корректный GTIN также не устанавливает владельца лежащих на складе экземпляров. Если два клиента хранят один товар, одинаковое описание товара может быть общим, а их остатки и обязательства должны оставаться раздельно проверяемыми. В рабочем шаблоне для этого есть owner_id.

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

Учебный разбор семи строк

Условный селлер сопоставляет данные WB, Ozon и ERP. Это иллюстрация процедуры, а не кейс клиента Skirbo. Все идентификаторы и коды вымышлены.

Строка Исходное различие Решение в примере
MAP-001 WB-A: 0012, чёрная футболка M, владелец A, 1 шт. Принять A-TS-M
MAP-002 OZ-A: другой артикул, тот же подтверждённый M и владелец A Принять тот же A-TS-M; сохранить оба подтверждённых баркода
MAP-003 WB-A: размер L с тем же кодом, что у M Оставить review; SKU не назначать до проверки
MAP-004 WB-B: тот же M и код, владелец B Принять отдельный B-TS-M; не присоединять чужой запас
MAP-005 WB-A: упаковка из двух футболок M Принять отдельную позицию упаковки A-TS-M-2P
MAP-006 ERP-A: артикул 12, вариант не установлен Оставить review; не дописывать нули и размер по догадке
MAP-007 ERP-A: другая позиция 000013, артикул 0012, M подтверждён Принять A-TS-M; ключ product_id:000013 отличен от product_id:000012 у MAP-006

На узком экране таблицу можно прокрутить вправо. С клавиатуры: Tab до таблицы, затем стрелки.

Получились пять принятых внешних связей и две спорные. Три принятые связи ведут к одному SKU; ещё две — к отдельным позициям другого владельца и упаковки. У MAP-006 и MAP-007 пустой внешний ID варианта, но разные типизированные ключи позиции ERP. Сокращение числа складских карточек здесь ничего не говорит об изменении количества вещей.

В очереди у MAP-003 записано, какую бирку и карточку размера запросить. У MAP-006 — какой документ восстановит вариант. Поле assignee назначает исполнителя следующего действия даже у открытого спора; поле reviewer остаётся пустым до принятого решения. Ответственный видит не только список «дублей», но и следующий шаг для каждой строки. Запуск всей группы пока преждевременен: история примера содержит ошибочную прежнюю привязку L к M, и её влияние на открытые обязательства ещё нужно проверить.

Как менять код или исправлять прежнюю связь

Если поставщик заменил штрихкод, сначала установите, что вариант, единица и комплектация действительно прежние. После подтверждения новая связь может вести к тому же складскому SKU. Старый код сохраняйте в истории вместе с периодом действия; если оба кода остаются на допустимых к продаже экземплярах, зафиксируйте оба действующих кода и проверьте оба сканирования. Если изменился состав или количество упаковки, это уже другая задача идентификации.

История должна отвечать на вопросы: что было раньше, что стало, когда изменение действует, на каком основании и кто его принял. Перед изменением обязательно сохраните полный предыдущий файл соответствий с версией, статусами и интервалами действия всех строк. Сделайте архив неизменяемым, сохраните контрольную сумму и доступную проверяющему ссылку. Укажите эту ссылку в previous_mapping_snapshot записей истории. Простая замена ячейки в текущей таблице не позволяет объяснить старый заказ или возврат.

Скачиваемая история — выборка изменений отдельных полей. Она сама по себе недостаточна для восстановления прежней версии: например, CHG-002 показывает смену SKU, но не все прежние статусы и интервалы. В учебном примере ссылка на полный предыдущий файл обозначена как вымышленный ориентир, сам файл не приложен. Для рабочего применения такой ориентир необходимо заменить настоящим архивом; пока его нет, полную восстановимость не считайте проверенной.

При исправлении ошибочного объединения проверьте затронутые заказы, резервы, остатки по местам и возвраты. Составьте их список до изменения. Не переносите старые обязательства на новую карточку автоматически вместе с переименованием. Для исправленной группы нужен согласованный порядок пересчёта и повторной проверки. Снимок данных и версия соответствий должны позволять восстановить прежнее состояние; откат только названия товара не исправит уже совершённые движения.

Когда каталог можно принять

Приёмка относится к выбранной товарной группе и конкретной версии, а не ко всем будущим импортам. Проверьте следующие условия:

  • Каждая исходная строка имеет принятое соответствие либо явное исключение. Исчезнувшие из отчёта строки не считаются обработанными.
  • У составного ключа «источник + кабинет + key_kind + key_value» есть не более одного действующего назначения. Отсутствующий ключ не считается совпадением. У принятой строки заполнены владелец, вариант, единица, основание и проверивший.
  • Варианты M и L, штука и упаковка, владельцы A и B остаются различимыми.
  • Повторная обработка того же среза не создаёт новые связи и не изменяет принятые решения без причины.
  • Старый заказ можно объяснить по прежним исходным ключам и версии; новая связь не стирает историю.
  • Количества по владельцам, местам и единицам согласованы с исходным учётом. Дополнительный баркод не создал дополнительный физический товар.
  • На контрольных строках проверены поиск, сканирование, обычный заказ и исключение. Неизвестное осталось видимым.

Если выгрузка обрезана, владелец неизвестен или варианты невозможно отличить по доступным данным, сначала восстановите источники. Массовая очистка не решает недостачу, неправильную приёмку или правила возврата маркированного экземпляра. Эти случаи требуют собственных процедур.

Следующий шаг: проверить свою связь в Skirbo

Возьмите небольшую обезличенную группу товаров: обычное совпадение, два похожих размера, второго владельца и упаковку. Заполните таблицу соответствий и оставьте спорные строки открытыми. Затем обсудите с поддержкой Skirbo, как эти данные сопоставляются в вашем подключении и как проверить результат на ограниченной группе.

К сообщению достаточно приложить схему колонок, пример неоднозначности и ожидаемое решение. Ключи API, персональные данные покупателей и полный клиентский каталог для первого разбора не нужны. Договоритесь, где будет виден результат сопоставления, кто проверит старые обязательства и при каком расхождении работа остановится. Описанная методика и таблицы не подтверждают автоматическое объединение всех таких сценариев в конкретном кабинете Skirbo.