Как организовать хранение и вывод штрихкодов Wildberries в 1С:Управление торговлей

← На главную

При работе с маркетплейсами, такими как Wildberries (WB), Ozon или Яндекс Маркет, пользователи часто сталкиваются с необходимостью хранить специфические идентификаторы товаров, которые не совпадают со штрихкодами производителей. В типовой конфигурации 1С:Управление торговлей 11 (УТ 11.4 / 11.5) предусмотрен регистр для хранения штрихкодов, но его структуры часто не хватает для разделения «своих» и «чужих» кодов. В этой статье мы подробно разберем несколько стратегий реализации этой задачи: от самых простых до профессиональных архитектурных решений.

Вариант 1. Использование дополнительных реквизитов

Это самый быстрый способ, не требующий изменения конфигурации или написания кода. Мы можем создать дополнительный реквизит для справочника Номенклатура (или Характеристики номенклатуры, если учет ведется в разрезе характеристик).

Преимущества:

Легко добавляется в пользовательском режиме.
Автоматически доступен в типовых отчетах через механизм «Изменить вариант».
Не требует участия программиста при обновлении конфигурации.

Недостатки:

Проанализируем ситуацию: если у вас один товар продается на пяти разных площадках, вам придется заводить пять доп. реквизитов. Как отмечают участники обсуждения, это «тупиковый путь» при масштабировании, так как помимо штрихкода могут понадобиться SKU ID, NM ID, Артикул поставщика на МП и другие данные. Если линеек товаров и площадок много, карточка товара станет перегруженной и неудобной для работы.

Вариант 2. Расширение типового регистра «Штрихкоды номенклатуры»

Типовой регистр сведений ШтрихкодыНоменклатуры хранит записи в связке с владельцем. Чтобы отделить штрихкоды Wildberries, мы можем добавить в него новый реквизит или измерение.

Разберем по шагам, как это лучше реализовать:

Создание перечисления: Создадим новое перечисление ТипыШтрихкодовМП со значениями: Собственный, Wildberries, Ozon, Яндекс.
Добавление реквизита: Через механизм расширений добавим в регистр ШтрихкодыНоменклатуры реквизит ТипШтрихкода (ссылка на наше перечисление).
Доработка отчетов: Чтобы вывести этот штрихкод в отчет, нам потребуется в схеме компоновки данных (СКД) добавить левое соединение с этим регистром, установив фильтр по полю ТипШтрихкода.

Рассмотрим пример запроса для получения штрихкода WB в отчете:


ВЫБРАТЬ
    Номенклатура.Ссылка КАК Товар,
    Штрихкоды.Штрихкод КАК ШтрихкодWB
ИЗ
    Справочник.Номенклатура КАК Номенклатура
    ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ШтрихкодыНоменклатуры КАК Штрихкоды
        ПО Штрихкоды.Номенклатура = Номенклатура.Ссылка
        И Штрихкоды.ТипШтрихкода = ЗНАЧЕНИЕ(Перечисление.ТипыШтрихкодовМП.Wildberries)

Вариант 3. Использование справочника «Номенклатура контрагентов»

В 1С:УТ 11 существует встроенный механизм для связи вашей номенклатуры с номенклатурой сторонних организаций. Поскольку Wildberries технически является вашим комиссионером (партнером), мы можем использовать справочник НоменклатураКонтрагентов.

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

Вариант 4. Создание независимой «Матрицы маркетплейсов»

Для крупных проектов с полноценной автоматизацией наиболее эффективным решением будет создание отдельной сущности. Выясним причину: маркетплейсы требуют не только хранения кода, но и управления остатками, ценами и связками между разными аккаунтами (например, два разных кабинета WB для разных юридических лиц).

Предлагается создать новый Регистр сведений (например, ДанныеТоваровМаркетплейсов) со следующей структурой:

Измерения:

Номенклатура (СправочникСсылка.Номенклатура)
Характеристика (СправочникСсылка.ХарактеристикиНоменклатуры)
АккаунтМаркетплейса (Справочник, где описаны ваши ЛК: WB ИП Иванов, WB ООО Ромашка и т.д.)

Ресурсы/Реквизиты:

Баркод (Строка)
ИдентификаторКарточки (NM ID)
ТипПоставки (FBO/FBS)

Посмотрим на пример логики распределения остатков в такой системе. Если мы знаем, какой штрихкод к какому аккаунту относится, мы можем реализовать программный код, который будет транслировать остатки из 1С в API конкретного маркетплейса:


Процедура ОбновитьОстаткиНаМаркетплейсе(Товар, Аккаунт)
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   ДанныеМП.Баркод,
        |   Остатки.ВНаличииОстаток КАК Количество
        |ИЗ
        |   РегистрСведений.ДанныеТоваровМаркетплейсов КАК ДанныеМП
        |   ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки( , Номенклатура = &Товар) КАК Остатки
        |   ПО ДанныеМП.Номенклатура = Остатки.Номенклатура
        |ГДЕ
        |   ДанныеМП.АккаунтМаркетплейса = &Аккаунт";
    
    Запрос.УстановитьПараметр("Товар", Товар);
    Запрос.УстановитьПараметр("Аккаунт", Аккаунт);
    // Далее — передача данных через HTTP-запрос в API WB
КонецПроцедуры

Выводы и рекомендации

Выбор метода зависит от ваших долгосрочных планов:

Если нужно «просто вывести поле в отчет» для одного-двух товаров и интеграция не планируется — используйте дополнительные реквизиты.
Если вы хотите сохранить чистоту архитектуры и использовать штатные средства УТ 11 — используйте номенклатуру контрагентов.
Если планируется масштабирование (много маркетплейсов, несколько юридических лиц) или внедрение полноценного API-обмена — создавайте собственный регистр сведений (Матрицу маркетплейсов). Это позволит избежать путаницы со штрихкодами производителей и обеспечит гибкость при изменении требований площадок.

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