Чем отличаются интеграции с Ozon и Wildberries в 1С?

[Odineski]

Расскажи про особенности интеграций озон и вб, насколько сильно они отличаются?

[Odin — Одинэсник]

Интеграции с Ozon и Wildberries похожи по бизнес-задаче, но технически это разные интеграции. Нельзя сделать один универсальный обмен, просто заменив адрес API и токен. Обычно делают общий интеграционный каркас и два отдельных адаптера: один для Ozon, второй для Wildberries.

## Что у них общее

В обеих интеграциях обычно требуется передавать и получать:

— номенклатуру;
— характеристики товаров;
— изображения;
— цены;
— скидки;
— остатки;
— заказы;
— статусы заказов;
— сборочные задания;
— отгрузки;
— отмены;
— возвраты;
— финансовые отчеты;
— отчеты по продажам и удержаниям;
— штрихкоды и этикетки;
— информацию о комиссиях и начислениях.

С точки зрения 1С типовая схема выглядит так:

1. В 1С хранится соответствие между номенклатурой и товаром маркетплейса.
2. Регламентное задание выгружает цены и остатки.
3. Обмен загружает заказы и создает документы в 1С.
4. После сборки заказов в маркетплейс передается информация об отгрузке.
5. Отдельно загружаются финансовые отчеты и возвраты.
6. Все запросы, ответы и ошибки сохраняются в журнале обмена.

Но на этом сходство в основном заканчивается.

—

# 1. Отличия авторизации

## Ozon

Для API Ozon обычно используются:

— Client-Id;
— API-ключ;
— отдельные методы Seller API;
— JSON-запросы и JSON-ответы.

Идентификация относительно простая: в запросе передаются учетные данные магазина, после чего вызываются методы API.

В 1С удобно хранить настройки в отдельном регистре или справочнике:

— идентификатор клиента;
— API-ключ;
— организация;
— склад;
— схема работы;
— признак тестового или рабочего подключения.

## Wildberries

У Wildberries интеграция чаще воспринимается не как один API, а как набор API для разных задач:

— заказы;
— остатки;
— карточки товаров;
— цены и скидки;
— статистика;
— отчеты;
— поставки;
— продвижение;
— контент;
— маркировка и работа с кодами.

Для разных групп методов могут использоваться разные токены и разные адреса сервисов. Кроме того, структура и доступность методов у Wildberries меняются достаточно активно.

Практическое следствие для 1С: нельзя рассчитывать, что один токен и один универсальный клиент закроют весь обмен. Лучше заранее предусмотреть хранение нескольких настроек подключения и разделить обмен по функциональным блокам.

—

# 2. Различия в модели товаров

## Ozon

У Ozon товар обычно имеет несколько важных идентификаторов:

— идентификатор товара в Ozon;
— артикул продавца;
— SKU;
— идентификатор offer;
— идентификатор категории;
— идентификатор типа товара;
— штрихкод.

При выгрузке карточки нужно учитывать категорийные атрибуты. У разных категорий свой набор характеристик, обязательных и необязательных полей.

В 1С желательно не пытаться хранить все характеристики только в реквизитах номенклатуры. Практичнее использовать отдельные таблицы соответствий:

— категория маркетплейса;
— характеристика маркетплейса;
— значение характеристики;
— значение характеристики в 1С;
— признак обязательности;
— тип значения;
— соответствие единиц измерения.

## Wildberries

У Wildberries карточка товара обычно связана с:

— артикулом продавца;
— nmID;
— imtID;
— vendorCode;
— баркодом;
— размерными характеристиками;
— предметом;
— брендом;
— категорией;
— характеристиками предмета;
— размерами.

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

Например, в 1С может быть товар:

> Кроссовки мужские

А в Wildberries это фактически несколько товарных вариантов:

— размер 41;
— размер 42;
— размер 43;
— размер 44.

Если в 1С не предусмотрены характеристики номенклатуры, можно неправильно передавать остатки, заказы и баркоды.

## Практический вывод

Для обеих площадок нужно хранить отдельное соответствие:

| Объект 1С | Ozon | Wildberries |
|—|—|—|
| Номенклатура | ID товара, SKU, offer | nmID, vendorCode |
| Характеристика | вариант товара | размер, цвет, вариант |
| Штрихкод | баркод/SKU | баркод |
| Категория | категория Ozon | предмет и категория WB |
| Склад | склад Ozon | склад или складская схема WB |

Нельзя использовать только артикул продавца как ключ. Артикул может измениться, повторяться или не быть уникальным в нужном контексте. Надежнее хранить внутренний идентификатор маркетплейса.

—

# 3. Цены и скидки

## Ozon

У Ozon цена может быть представлена несколькими значениями:

— цена до скидки;
— цена продавца;
— цена с учетом скидок;
— минимальная цена;
— цена для разных схем или условий;
— комиссии и другие составляющие.

Важно заранее определить, какую именно цену должна передавать 1С:

— розничную цену из 1С;
— цену продавца;
— цену до скидки;
— минимально допустимую цену;
— цену с учетом маркетинговых акций.

Если просто передавать одну цену без правил, можно получить ситуацию, когда цена в 1С и цена на витрине Ozon отличаются из-за скидок, акций или настроек площадки.

## Wildberries

У Wildberries цена и скидка также разделяются. Обычно отдельно участвуют:

— базовая цена;
— скидка продавца;
— итоговая цена;
— скидка площадки;
— участие в акциях;
— коэффициенты и условия конкретной категории.

Для Wildberries особенно важно не смешивать:

— скидку продавца;
— скидку WB;
— комиссию;
— итоговую цену покупателя;
— сумму, которую получит продавец.

Это разные показатели.

## Как правильно реализовать в 1С

В 1С лучше хранить не одно поле «Цена маркетплейса», а отдельные значения:

— Цена продавца;
— Цена до скидки;
— Скидка продавца;
— Цена после скидки;
— Цена по данным маркетплейса;
— Дата последней выгрузки;
— Дата последнего успешного ответа;
— Текст ошибки по цене.

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

—

# 4. Остатки

## Общий принцип

Остатки передаются не просто по товару, а чаще всего по связке:

> маркетплейс + склад + товар + вариант товара

В 1С нужно определить источник остатка:

— остаток на складе;
— свободный остаток;
— остаток за вычетом резерва;
— остаток с учетом минимального остатка;
— остаток с учетом уже загруженных заказов;
— остаток, доступный конкретной схеме работы.

Например:

1С (Код)

Доступно к продаже = Остаток на складе - Резерв под заказы - Минимальный страховой остаток - Остаток, недоступный для маркетплейса

1 2 3 4 5

Доступно к продаже = Остаток на складе - Резерв под заказы - Минимальный страховой остаток - Остаток, недоступный для маркетплейса

## Ozon

У Ozon остатки зависят от схемы исполнения заказа:

— FBO, товар хранится на складе Ozon;
— FBS, товар хранится у продавца;
— realFBS, продавец самостоятельно организует доставку.

Для FBO остатки обычно являются результатом поставок на склад Ozon и не должны рассчитываться так же, как остатки FBS.

Для FBS 1С должна передавать доступный остаток по складам, которые участвуют в отгрузке.

## Wildberries

У Wildberries встречаются схемы:

— FBW, хранение на складе Wildberries;
— FBS, сборка продавцом;
— DBS, доставка продавцом;
— другие варианты в зависимости от действующих возможностей кабинета и региона.

Особое внимание нужно уделить складам и остаткам по размерам. Для размерных товаров нельзя передавать общий остаток на модель вместо остатка конкретного размера.

Пример ошибки:

1С (Код)

Товар: Футболка Общий остаток: 20

1 2	Товар: Футболка Общий остаток: 20

Для Wildberries чаще нужно передавать:

1С (Код)

Футболка, размер S: 5 Футболка, размер M: 8 Футболка, размер L: 7

1 2 3

Футболка, размер S: 5 Футболка, размер M: 8 Футболка, размер L: 7

## Главное различие

У Ozon логика остатков обычно воспринимается как остаток товара по складам и схемам продаж.

У Wildberries к остаткам сильнее привязаны:

— склады продавца;
— размеры;
— баркоды;
— поставки;
— сборочные задания;
— конкретные складские операции.

—

# 5. Заказы и статусы

Это один из самых важных участков интеграции.

## Ozon

У Ozon заказ обычно проходит через состояния, связанные с:

— созданием отправления;
— ожиданием сборки;
— сборкой;
— готовностью к передаче;
— передачей в доставку;
— доставкой;
— получением;
— отменой;
— возвратом.

При этом в заказе могут присутствовать:

— номер заказа;
— номер отправления;
— товары;
— количество;
— цена;
— стоимость доставки;
— схема работы;
— пункт отгрузки;
— дата доставки;
— статус;
— причины отмены;
— данные по возврату.

Особенность Ozon: заказ и отправление не всегда следует воспринимать как одно и то же. Один заказ может быть разделен на несколько отправлений или иметь отдельные логистические сущности.

В 1С нужно разделять:

— заказ покупателя;
— отправление;
— сборочное задание;
— отгрузку;
— возврат.

## Wildberries

У Wildberries большое значение имеют:

— заказы;
— сборочные задания;
— поставки;
— коробки;
— шк;
— баркоды;
— стикеры;
— статусы готовности;
— передача в доставку.

Для FBS типовой сценарий выглядит примерно так:

1. 1С получает новые заказы.
2. По заказам формируются сборочные задания.
3. В 1С создается заказ или документ реализации.
4. Выполняется сборка.
5. Получаются или формируются этикетки.
6. Передается информация о готовности.
7. Заказ включается в поставку.
8. Формируется транспортная или складская информация.
9. Поставка передается в пункт приема или курьеру.
10. Затем загружаются дальнейшие статусы.

У Wildberries заказ часто теснее связан с операцией сборки и передачей поставки. Поэтому простого обмена «загрузили заказ, создали реализацию» недостаточно.

## Рекомендация для 1С

Не храните статус только в документе заказа. Нужны отдельные поля или регистр состояния обмена:

— внешний идентификатор;
— внутренний документ 1С;
— текущий статус площадки;
— последний обработанный статус;
— дата получения статуса;
— дата передачи следующего состояния;
— текст ошибки;
— количество попыток;
— признак необходимости ручной обработки.

Статусы маркетплейсов не нужно напрямую записывать в стандартный статус документа 1С без таблицы соответствий.

Например:

| Статус маркетплейса | Состояние в 1С |
|—|—|
| Новый | Получен |
| Ожидает сборки | К сборке |
| Собран | Собран |
| Передан в доставку | Отгружен |
| Доставлен | Выполнен |
| Отменен | Отменен |
| Возвращен | Возврат |

Таблица должна быть отдельной для Ozon и Wildberries.

—

# 6. Этикетки, штрихкоды и маркировка

## Ozon

В зависимости от схемы работы могут использоваться:

— этикетки отправлений;
— штрихкоды;
— идентификаторы упаковок;
— данные для отгрузки;
— документы и файлы, связанные с логистикой.

Формат файлов и способ получения этикеток нужно проверять по конкретной схеме работы и актуальной версии API.

## Wildberries

У Wildberries этикетки и штрихкоды являются особенно важной частью FBS-процесса.

В интеграции могут участвовать:

— баркод товара;
— ШК;
— стикер;
— этикетка заказа;
— этикетка короба;
— идентификатор поставки;
— информация о коробах;
— данные для пункта приема.

Нельзя считать заказ полностью обработанным после его загрузки в 1С. Для Wildberries он должен пройти логистическую цепочку, включающую сборку и передачу.

## Маркировка

Для маркируемых товаров нельзя ограничиваться обменом только с маркетплейсом. В 1С нужно учитывать:

— коды маркировки;
— агрегацию;
— выбытие;
— возвраты;
— повторную реализацию;
— связь кода с конкретной единицей товара;
— статус проверки кода.

Маркетплейс может сообщать об ошибке уже на этапе приемки или продажи, поэтому контроль кодов должен выполняться до отправки заказа.

—

# 7. Возвраты и отмены

## Ozon

Возврат может быть отражен через:

— отмену до передачи;
— отказ покупателя;
— возврат после получения;
— возврат товара на склад;
— финансовую корректировку;
— удержание комиссии или стоимости логистики.

В 1С важно разделить:

— отмену заказа;
— возврат денежных средств;
— физический возврат товара;
— финансовую корректировку;
— повторное поступление товара на склад.

## Wildberries

У Wildberries возвраты часто связаны с:

— отказом покупателя;
— возвратом из пункта выдачи;
— обратной логистикой;
— приемкой возврата;
— удержаниями;
— отчетом реализации;
— отчетом по удержаниям и услугам.

В финансовых отчетах возврат может отражаться не так, как ожидает бухгалтер. Поэтому нельзя строить бухгалтерские документы только по статусу заказа.

Лучше использовать отдельный процесс:

1. Загрузить операционные данные по заказу.
2. Загрузить фактическую реализацию.
3. Загрузить возврат.
4. Загрузить финансовый отчет.
5. Сверить суммы.
6. Только после сверки формировать документы в бухгалтерском или управленческом контуре.

—

# 8. Финансовые отчеты

Это участок, где различия наиболее заметны для бухгалтерии.

Оба маркетплейса могут разделять:

— стоимость товара;
— комиссию;
— логистику;
— хранение;
— обработку;
— рекламу;
— штрафы;
— возвраты;
— компенсации;
— прочие удержания;
— сумму к перечислению.

Но состав и структура отчетов отличаются.

## Ozon

Финансовые данные могут приходить в разрезе:

— отправлений;
— товаров;
— операций;
— начислений;
— удержаний;
— периода;
— договора;
— схемы реализации.

## Wildberries

У Wildberries финансовые отчеты обычно требуют более сложного сопоставления:

— заказ;
— продажа;
— возврат;
— отчетный период;
— поставка;
— склад;
— комиссия;
— логистика;
— штраф;
— удержание;
— сумма к перечислению.

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

Рекомендуемые регистры или документы в 1С:

— Реализация маркетплейса;
— Возвраты маркетплейса;
— Услуги маркетплейса;
— Комиссии маркетплейса;
— Штрафы и удержания;
— Сверка расчетов с маркетплейсом;
— Реестр расхождений.

—

# 9. Частота обмена и ограничения API

Оба сервиса имеют ограничения по частоте запросов. Это нельзя решать бесконечным циклом запросов из 1С.

Неправильный вариант:

1С (Код)

Для каждого товара Отправить отдельный HTTP-запрос КонецЦикла

1 2 3

Для каждого товара     Отправить отдельный HTTP-запрос КонецЦикла

При большом ассортименте такой обмен быстро упрется в лимиты.

Правильнее:

— использовать пакетные методы;
— выгружать только измененные товары;
— разделять обмен по направлениям;
— сохранять дату последней успешной загрузки;
— использовать повторные попытки с задержкой;
— не повторять бесконечно один и тот же ошибочный запрос;
— хранить очередь обмена;
— вести журнал результата каждого пакета.

## Очередь обмена

В 1С полезно иметь регистр сведений примерно с такими полями:

— маркетплейс;
— вид операции;
— объект 1С;
— внешний идентификатор;
— дата постановки в очередь;
— состояние;
— количество попыток;
— дата последней попытки;
— текст ошибки;
— дата успешной отправки;
— приоритет.

Тогда ошибка по одному товару не остановит выгрузку всех остальных.

—

# 10. Насколько сильно они отличаются

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

Если говорить с точки зрения разработки 1С, отличия существенные:

— разные модели товаров;
— разные идентификаторы;
— разные правила категорий;
— разные статусы;
— разные сценарии сборки;
— разные форматы отчетов;
— разные правила работы со складами;
— разные способы получения этикеток;
— разные ограничения API;
— разные требования к токенам;
— разные особенности возвратов.

Условно можно сказать так:

| Участок | Сходство | Отличия |
|—|—:|—:|
| Товары | Высокое | Средние |
| Цены | Среднее | Средние |
| Остатки | Высокое | Существенные |
| Заказы | Среднее | Существенные |
| Сборка FBS | Среднее | Очень существенные |
| Этикетки | Низкое | Существенные |
| Возвраты | Среднее | Существенные |
| Финансы | Среднее | Очень существенные |
| Авторизация | Низкое | Существенные |
| Лимиты API | Низкое | Существенные |

Практически это означает:

— общий модуль HTTP-клиента использовать можно;
— общий журнал обмена использовать можно;
— общую очередь обмена использовать можно;
— общую таблицу соответствий частично использовать можно;
— обработчики товаров, заказов, статусов, сборки и отчетов лучше делать раздельными.

—

# Как лучше строить интеграцию в 1С

## Общая часть

В общей части можно реализовать:

— настройки подключения;
— хранение токенов;
— HTTP-клиент;
— сериализацию JSON;
— журнал обмена;
— очередь запросов;
— повторные попытки;
— контроль лимитов;
— протоколирование;
— механизм сопоставления номенклатуры;
— обработку технических ошибок;
— контроль дублей.

## Отдельный адаптер Ozon

В нем должны находиться:

— загрузка товаров Ozon;
— выгрузка карточек Ozon;
— передача цен;
— передача остатков;
— получение отправлений;
— обновление статусов;
— получение этикеток;
— загрузка возвратов;
— загрузка финансовых операций.

## Отдельный адаптер Wildberries

В нем отдельно реализуются:

— карточки товаров WB;
— характеристики и размеры;
— баркоды;
— цены и скидки;
— остатки по складам;
— заказы;
— сборочные задания;
— стикеры;
— поставки;
— статусы;
— возвраты;
— отчеты реализации;
— удержания и услуги.

Не стоит делать в общем модуле процедуру вида:

1С (Код)

ВыгрузитьТоварНаМаркетплейс()

1	ВыгрузитьТоварНаМаркетплейс()

Лучше определить общий интерфейс, но реализацию сделать разной:

1С (Код)

ВыгрузитьТоварНаOzon() ВыгрузитьТоварНаWildberries()

1 2	ВыгрузитьТоварНаOzon() ВыгрузитьТоварНаWildberries()

А общими оставить только подготовку данных из 1С и техническую обработку обмена.

—

# Что чаще всего ломается

## Ozon

На практике проблемы чаще возникают из-за:

— неправильного сопоставления SKU;
— путаницы между ценой продавца и ценой на витрине;
— смешения FBO и FBS;
— некорректных категорийных характеристик;
— попытки создать карточку с неполным набором обязательных полей;
— неверного понимания отправления и заказа;
— дублей при повторной отправке;
— разницы между операционным заказом и финансовой операцией.

## Wildberries

Наиболее частые проблемы:

— один товар в 1С не разделен по размерам;
— перепутаны nmID, артикул продавца и баркод;
— неправильно переданы остатки по складам;
— заказ загружен, но не обработано сборочное задание;
— не получены стикеры;
— не сформирована поставка;
— статусы заказа обработаны в неправильном порядке;
— финансовый отчет сопоставляется с заказом один к одному;
— использован не тот API-токен;
— обмен построен на старых методах API.

—

# Что выбрать для типовой задачи

Если требуется только:

— выгрузка цен;
— выгрузка остатков;
— загрузка заказов;
— создание документов в 1С;

то обе интеграции можно реализовать относительно компактно.

Если требуется полноценная автоматизация FBS, включая:

— сборочные задания;
— этикетки;
— поставки;
— статусы;
— возвраты;
— маркировку;
— финансовую сверку;

то Wildberries обычно требует более сложной операционной модели.

Если основной сценарий связан с FBO, то в обеих системах значительная часть складской логистики остается на стороне маркетплейса, но финансовая и товарная сверка все равно требует отдельной реализации.

Для 1С я бы проектировал интеграцию не как «обмен с маркетплейсом», а как два независимых внешних контура:

1С (Код)

1С | +-- Ozon Adapter | +-- Wildberries Adapter

1 2 3 4 5

1С | +-- Ozon Adapter | +-- Wildberries Adapter

При этом данные в 1С должны разделяться по уровням:

1. НСИ и соответствия.
2. Цены.
3. Остатки.
4. Заказы.
5. Отгрузки.
6. Возвраты.
7. Финансовые операции.
8. Ошибки и очередь обмена.

Такой подход позволит менять правила Ozon, не ломая обмен с Wildberries, и наоборот.

[Автор]

Записи