При интеграции 1С с маркетплейсами через API одной из ключевых задач становится выбор надежного способа сопоставления товаров. Часто начинающие разработчики и пользователи ограничиваются простым совпадением по артикулу, однако на практике это приводит к ряду сложностей. Рассмотрим подробнее, почему стандартного поля Артикул в карточке Номенклатура бывает недостаточно, и какие архитектурные решения существуют для корректного обмена данными.
Прежде чем перейти к технической реализации, выясним причину необходимости хранения этих данных. Синхронизация по артикулу поставщика — это лишь верхушка айсберга. Хранение специфических ID маркетплейсов (таких как SKU, Offer ID, nmID) необходимо для решения следующих задач:
Номенклатура будет невозможно, как и создание задач для ответственных сотрудников.Проанализируем ситуацию с точки зрения выбора инструмента реализации в среде 1С:Предприятие.
Для небольших магазинов с одним личным кабинетом на маркетплейсе самым быстрым решением будет использование механизма ДополнительныеСведения. Это позволяет добавить в карточку товара новые поля без изменения конфигурации.
Разберем по шагам, как это работает:
В справочнике Номенклатура создаются дополнительные сведения с именами вроде "Артикул WB" или "SKU Ozon". Программа позволяет выводить эти поля в списки и использовать их в запросах при выгрузке данных. Однако у этого метода есть существенный минус: он реализует связь "один к одному". Если у вас появится второй магазин или товар будет дублироваться в разных категориях маркетплейса, этот метод перестанет работать.
Если требуется надежная архитектура, посмотрим на пример создания специализированного регистра сведений. Это решение наиболее гибкое и позволяет хранить историю связей и работать с несколькими площадками одновременно.
Рекомендуемая структура регистра (например, с именем СоответствиеНоменклатурыМаркетплейсов):
Измерения:
Маркетплейс (Тип: Перечисление или Справочник) — указывает, к какой площадке относится запись.ЛичныйКабинет (Тип: Справочник) — если у вас несколько аккаунтов на одной площадке.ИдентификаторТовараНаМаркетплейсе (Тип: Строка) — тот самый внутренний ID (SKU, nmID).Ресурсы:
Номенклатура (Тип: СправочникСсылка.Номенклатура).Характеристика (Тип: СправочникСсылка.ХарактеристикиНоменклатуры).Проанализируем пример кода для получения артикула маркетплейса при выгрузке остатков, включая механизмы обработки ответов сервера:
Функция ПолучитьИдентификаторМП(ТоварСсылка, ВыбранныйМаркетплейс) Экспорт
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Соответствие.ИдентификаторТовараНаМаркетплейсе КАК ID
|ИЗ
| РегистрСведений.СоответствиеНоменклатурыМаркетплейсов КАК Соответствие
|ГДЕ
| Соответствие.Номенклатура = &Номенклатура
| И Соответствие.Маркетплейс = &Маркетплейс";
Запрос.УстановитьПараметр("Номенклатура", ТоварСсылка);
Запрос.УстановитьПараметр("Маркетплейс", ВыбранныйМаркетплейс);
Результат = Запрос.Выполнить();
Если Не Результат.Пустой() Тогда
Выборка = Результат.Выбрать();
Выборка.Следующий();
Возврат Выборка.ID;
КонецЕсли;
Возврат "";
КонецФункции
В современных конфигурациях, таких как 1С:Управление нашей фирмой 3.0 или 1С:Управление торговлей 11.5, разработчики 1С уже предусмотрели штатные подсистемы для работы с маркетплейсами. Рассмотрим подробнее, как это реализовано в типовых модулях.
Система использует справочники НоменклатураМаркетплейсов или специализированные регистры сопоставления. Основное преимущество типового подхода заключается в том, что 1С хранит не только артикул, но и состояние публикации карточки, ошибки модерации и текущую категорию товара на площадке.
В УНФ 3.0 для этого выделено целое рабочее место в разделе "Продажи" — "Маркетплейсы". Разберем по шагам процесс синхронизации:
Сначала вы загружаете список товаров из личного кабинета маркетплейса. Система создает записи в таблице сопоставления, где для каждой позиции маркетплейса указывается соответствующая Номенклатура в базе. Это позволяет избежать дублирования артикулов и корректно обрабатывать заказы.
При проектировании системы хранения важно понимать, что именно мы сохраняем. Выясним специфику основных игроков рынка:
vendorCode (артикул продавца) и barcode (штрихкод). Однако для работы через API версии 3.0 и выше критически важно сохранять nmID — уникальный номер карточки WB.Offer ID (ваш уникальный артикул) и SKU ID. Причем у одного и того же товара могут быть разные SKU для схем работы со своего склада (FBS) и со склада маркетплейса (FBO).Shop SKU. Важно помнить, что Яндекс позволяет "привязываться" к чужим карточкам товаров, поэтому артикул производителя может не совпадать с вашим внутренним кодом.Часто возникает вопрос: "Почему бы не использовать типовой регистр ШтрихкодыНоменклатуры для хранения артикулов маркетплейсов?". Проанализируем этот момент. Штрихкод в 1С предназначен для идентификации физической единицы товара при сканировании. Если вы начнете записывать в этот регистр все технические коды маркетплейсов, вы рискуете "засорить" базу. При обычном складском сканировании система может находить десятки соответствий для одного кода, что создаст ошибки при приемке или отгрузке. Для идентификаторов маркетплейсов лучше использовать отдельное хранилище.
Подводя итог, выясним наиболее правильную стратегию: Если вы используете современную конфигурацию (УНФ 3.0, УТ 11.5), в первую очередь изучите возможности встроенного модуля интеграции. В большинстве случаев он уже содержит необходимые механизмы сопоставления.
Если же вы пишете собственную интеграцию или используете старые версии программ, мы рекомендуем создать отдельный регистр сведений. Это обеспечит масштабируемость вашего бизнеса: вы сможете легко добавлять новые площадки, работать с несколькими аккаунтами и корректно сопоставлять сложные товары (наборы, характеристики, упаковки) без риска потери данных при обновлении конфигурации.