Интеграция 1С с маркетплейсами: заказы, цены, остатки и ошибки обмена

Что входит в интеграцию 1С с маркетплейсами?

Слово «интеграция» скрывает несколько независимых потоков. Их нужно перечислить до выбора модуля или оценки разработки. Официальная страница 1С показывает, что состав функций отличается даже внутри типового решения: для одних площадок доступны каталог, цены, остатки, FBS-заказы, поставки и отчёты, а для других - только часть операций.

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

Как модель FBS или FBO меняет обмен?

При FBS товар хранится у продавца. Площадка передаёт заказ, продавец резервирует товар, собирает отправление и передаёт его в логистический контур маркетплейса. Здесь критичны оперативные остатки, скорость получения новых заданий, корректные статусы и защита от повторной загрузки заказа.

При FBO, FBY или FBW товар размещён на складе площадки. Продавец планирует поставки, передаёт каталог и цены, получает сведения о продажах, возвратах и движении товара. Собственный склад 1С и доступный остаток на площадке отражают разные физические контуры. Копирование одного числа в другое даст неверную картину.

Компания может использовать несколько схем одновременно. Тогда признак схемы должен быть частью настроек товара и склада, а не устной договорённостью сотрудников.

Где хранить исходные товары, цены и заказы?

Главный проектный вопрос звучит не «как часто запускать обмен», а «кто имеет право изменить это поле». Каждое поле получает одну систему-источник. Другая система может использовать значение или отправить запрос на изменение, но не переписывает его независимо.

Что выбрать: типовую интеграцию, готовый модуль или собственный API?

В актуальных конфигурациях 1С могут быть рабочие места и сервисы обмена с Ozon, Wildberries, Яндекс Маркетом и другими площадками. Этот путь стоит проверять первым, но само название маркетплейса в списке поддержки ещё не подтверждает нужный бизнес-процесс.

Готовый модуль демонстрируют на собственных данных, включая ошибочные сценарии. Для заказной разработки сначала проводят диагностику по принципам интеграции по API и фиксируют границы в техническом задании.

Как сопоставить товары и варианты?

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

1. Выбрать мастер-систему. Определить, где создаётся исходный товар и его варианты.
2. Закрепить внутренний артикул. Каждый продаваемый вариант получает устойчивый ключ.
3. Сохранить ID площадки. После создания или сопоставления карточки связь записывается отдельно по кабинету.
4. Заблокировать неподтверждённый обмен. Цена и остаток не уходят, пока связь товара неоднозначна.
5. Создать очередь разбора. Несопоставленные позиции не создаются автоматически по похожему названию.
6. Сохранить историю. Архивирование карточки не удаляет связь со старыми заказами.

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

Как синхронизировать цены?

У цены на маркетплейсе несколько контекстов: исходная цена продавца, действующая цена, скидка, участие в акции, ограничения и фактическая сумма в заказе. Нельзя предполагать, что одно поле 1С полностью описывает все эти значения.

• определить, где рассчитывается цена и кто её согласует;
• связать тип цены, валюту и кабинет продавца;
• разделить собственную цену и механику акции площадки;
• сохранять рассчитанное, отправленное и подтверждённое значение;
• показывать сотруднику фактически опубликованный результат;
• обрабатывать массовые обновления пакетами в пределах актуальных лимитов API;
• не повторять отклонённый запрос без исправления причины.

Успешный HTTP-ответ не всегда означает, что цена прошла проверки и стала активной. Если API возвращает задание или отдельный результат обработки, интеграция должна дождаться финального состояния. Лимиты и методы читают из актуальной документации Ozon или Wildberries во время реализации, а не зашивают из статьи навсегда.

Как передавать остатки без перепродажи?

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

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

Как загружать заказы и возвращать статусы?

У каждого заказа должен быть неизменяемый внешний идентификатор. Уникальное ограничение на связку «площадка + кабинет + внешний ID» блокирует дубль, а идемпотентная логика по этому ключу возвращает или обновляет существующий результат.

1. 01

   Получить событие

   Сохранить исходный ответ API и внешний идентификатор до обработки.

2. 02

   Проверить контекст

   Определить кабинет, организацию, склад, схему и сопоставление товаров.

3. 03

   Провести идемпотентно

   Создать или обновить один документ 1С и связать его с внешним заказом.

4. 04

   Зарезервировать

   Зафиксировать доступное количество по правилам компании.

5. 05

   Передать статус

   Выполнить только разрешённый переход состояния площадки.

6. 06

   Записать результат

   Сохранить попытку, ответ и итоговый бизнес-статус в журнале.

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

Как учитывать возвраты и финансовые отчёты?

Операционный заказ отвечает на вопрос «что нужно отгрузить». Финансовый отчёт площадки отвечает на вопрос «что признано продажей, возвращено или удержано». Это разные источники и разные моменты времени. Если строить бухгалтерский результат только по заказам, сверка будет расходиться из-за отмен, возвратов, корректировок и услуг площадки.

• загружать документы и отчёты площадки отдельным потоком;
• связывать строки с заказами и товарами по устойчивым идентификаторам;
• сохранять оригинальный документ или ссылку на него;
• выводить несопоставленные строки в очередь проверки;
• проводить корректировки по правилам учёта компании;
• не возвращать товар в продажу до фактической приёмки и проверки состояния.

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

Какие ошибки обмена возникают чаще всего?

Ошибку полезно рассматривать не как текст из API, а как состояние бизнес-операции. Интеграция должна понимать, можно ли безопасно повторить запрос, нужно ли исправление данных или требуется решение сотрудника.

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

Как защитить интеграцию?

Ключ API открывает доступ к коммерческим данным и операциям продавца. Его считают секретом, а интеграционный сервис - частью критичного контура. В документации WB API категории доступа разделены между контентом, аналитикой, ценами, маркетплейсом, статистикой и другими блоками; предусмотрен и режим только для чтения. Интеграции не нужен максимальный доступ «на всякий случай».

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

Как провести пилот и принять результат?

Пилот ограничивают одной площадкой, кабинетом, схемой работы и контролируемой группой товаров. Его цель - доказать маршрут данных, а не сразу подключить весь ассортимент.

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

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

От чего зависит объём проекта?

Стоимость и срок нельзя определить только по фразе «интеграция 1С с Ozon и Wildberries». На объём влияют конфигурация 1С, модели торговли, число кабинетов и складов, качество справочника, правила резервирования и цены, возвраты, отчёты, маркировка и требования к восстановлению.

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

Частые вопросы