Автоматизация загрузки заказов с маркетплейсов в 1С

Как настроить обмен заказами с Wildberries, Ozon и Яндекс Маркетом и не потерять данные при росте продаж

Пока продаж на маркетплейсе немного, менеджер вполне успевает вручную переносить заказы из личного кабинета площадки в 1С: смотреть новые заказы, вбивать состав, резервировать остаток, распечатывать этикетку. Как только заказов становится десятки или сотни в день, а площадок — несколько, ручной перенос начинает регулярно давать сбои: заказ забыли перенести, остаток не зарезервировали вовремя, продали то, чего физически уже нет на складе.

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

Что значит «загрузка заказов в 1С» и зачем она нужна

Технически у продавца на маркетплейсе всегда два места, где живут данные о заказе: личный кабинет площадки (там заказ появился) и учётная система — чаще всего 1С (там его нужно обработать: зарезервировать товар, оформить отгрузку, отразить продажу для бухгалтерии). Интеграция — это настроенный канал обмена данными между этими двумя системами, который забирает эту работу у человека.

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

• сам заказ — состав, количество, адрес доставки, статус — если продавец собирает и отгружает товар сам (схема FBS);
• только сводный отчёт о продажах — если площадка хранит товар у себя и полностью ведёт сборку и доставку (схема FBO у Ozon, FBW у Wildberries, FBY у Яндекс Маркета).

Как устроен процесс обмена

FBS: заказ формируется у продавца

При работе по FBS (Fulfillment by Seller) товар хранится на складе продавца. Когда покупатель оформляет заказ, площадка передаёт продавцу заказ, статус которого меняется по ходу обработки: у Wildberries такой заказ называется «сборочным заданием» и проходит через статусы получения, сборки и передачи в доставку [1]. Именно эти статусы и состав заказа нужно оперативно получать в 1С, чтобы вовремя зарезервировать товар, распечатать этикетку и подтвердить отгрузку в срок — иначе площадка может применить санкции за нарушение сроков отгрузки.

FBO/FBY: в 1С попадает не заказ, а отчёт

Если товар хранится на складе площадки и она сама собирает и доставляет заказы, продавцу не нужно реагировать на каждый отдельный заказ в реальном времени. Для схемы FBO в большинстве случаев достаточно загружать в учётную систему только отчёт комиссионера — следить за каждым конкретным заказом через интеграцию в этом случае не требуется [2]. В 1С обычно загружают периодический сводный документ, на основании которого бухгалтерия отражает реализацию.

Механика обмена по API: токены, методы, статусы, уведомления

Все три крупнейшие площадки дают продавцам официальный REST API с открытой документацией для разработчиков. У Wildberries есть интерактивная Swagger-документация, где можно протестировать метод получения заказов ещё до написания кода [3]. У Ozon — Seller API: для работы с ним в личном кабинете нужно сгенерировать API-ключ и Client-Id, а сама документация регулярно обновляется — например, добавляются новые обязательные поля в методы работы с отправлениями FBS [4]. Процесс работы с Seller API делится на блоки — категорийное дерево и атрибуты товара, загрузка и обновление товаров, управление остатками, ценами и заказами FBS, rFBS и FBO; важная деталь — Seller API работает по UTC-0, и это нужно учитывать при обработке дат заказов [5]. Отдельный справочник методов охватывает логистику: списки отправлений, отмену постингов, работу с отгрузками [6].

У Яндекс Маркета — партнёрский API, который закрывает практически весь набор действий, доступных в личном кабинете: можно получать список новых заказов методом GET campaigns/{campaignId}/orders, а вместо регулярного опроса площадка рекомендует настроить API-уведомления — она сама отправит запрос при появлении нового заказа [7]. API Маркета работает с тремя моделями подключения — DBS (доставка силами продавца), FBS (фулфилмент продавца) и FBY (фулфилмент Яндекса) [8].

Для получения новых заказов используется один из двух подходов:

• регулярный опрос (поллинг) — учётная система сама с заданной периодичностью запрашивает список новых или изменившихся заказов;
• API-уведомления (вебхуки) — площадка сама уведомляет систему продавца о появлении нового заказа, что снижает задержку по сравнению с регулярной проверкой [7].

Общая последовательность работы модуля обмена почти всегда одна: получить список заказов → сопоставить товарные позиции площадки с номенклатурой 1С по артикулу или штрихкоду → создать в 1С соответствующий документ (заказ покупателя, реализация с признаком комиссии) → отследить смену статуса на площадке и синхронизировать её обратно в 1С → обработать ошибки API (лимиты запросов, таймауты, некорректные ответы).

Российская специфика

Комиссионная (агентская) схема и НДС

Юридически площадка не покупает товар у продавца — она реализует его по посредническому договору за комиссию, удерживая процент со стоимости [9]. Поэтому передача товара на площадку оформляется в 1С не обычной продажей, а документом «Реализация. Товары, услуги, комиссия»: документы конечным покупателям формирует сама площадка, а по итогам продаж она присылает отчёт комиссионера о розничных продажах; услуги площадки (комиссия, логистика, эквайринг) оформляются отдельным документом поступления услуг [10]. Такая схема требует настройки договора комиссии в 1С ещё до подключения обмена по API — иначе документы обмена просто не с чем будет сопоставлять [11].

Маркировка «Честный знак» при FBS

Если продавец торгует товаром, подлежащим обязательной маркировке, при схеме FBS именно продавец отвечает за вывод кодов маркировки из оборота в момент продажи — площадка этого не делает [12]. Сроки и порядок передачи кодов отличаются у разных площадок: Ozon разрешает вносить коды в любой момент до передачи заказа в доставку, но вывод из оборота всё равно остаётся обязанностью продавца; Яндекс Маркет по FBS даёт трёхдневный срок на вывод марок [13]. При FBO ответственность распределена иначе: коды проданных товаров выходят из оборота при регистрации соответствующих документов, а часть операций по маркировке берёт на себя сама площадка [14]. Это значит, что интеграция обмена заказами для маркированных товаров должна не просто передавать состав заказа, а связывать конкретные коды маркировки с конкретным заказом и контролировать сроки их вывода.

Реестр отечественного ПО и «1С:Совместимо»

Для компаний, которым важно использовать сертифицированные решения, часть модулей интеграции с маркетплейсами проходит проверку совместимости в каталоге «1С:Совместимо» — отдельной площадке фирмы «1С», где перечислены решения, прошедшие тестирование на типовых конфигурациях [15]. При выборе стороннего модуля стоит проверить его наличие в этом каталоге — это косвенный показатель того, что решение поддерживается и обновляется вместе с изменениями API площадок.

Варианты реализации

Встроенный функционал 1С

В отдельных редакциях типовых конфигураций 1С уже есть встроенные инструменты для обмена с крупнейшими площадками, но по умолчанию они рассчитаны на одно юридическое лицо и один склад — для схем с несколькими юрлицами или складами их возможностей может не хватить [16]. В 1С:УНФ типового функционала для части площадок нет вовсе — для обмена нужно ставить отдельное расширение из «Магазина расширений» или «Каталога расширений» [11].

Готовые модули расширений

Рынок предлагает множество платных модулей-расширений от разных разработчиков и партнёров фирмы «1С» [18], которые устанавливаются поверх типовой конфигурации и добавляют раздел управления маркетплейсами: сопоставление номенклатуры, обработку заказов, печать этикеток, загрузку отчётов комиссионера. Такие модули закрывают типовые сценарии быстрее, чем разработка с нуля, но продавец зависит от того, насколько оперативно разработчик модуля успевает адаптироваться к изменениям API площадки: часть готовых расширений не поддерживается в базовых версиях 1С, и доработку под конкретный процесс приходится заказывать отдельно у разработчика модуля [17].

Индивидуальная интеграция по API

Для нетиповых процессов — например, нескольких юридических лиц с распределением заказов по регионам и складам — оправдана индивидуальная разработка обмена по API. Пример из практики: при работе от четырёх юридических лиц с разделением по регионам и ассортименту потребовался модуль, который поддерживает работу с несколькими организациями и автоматически выбирает нужное юрлицо в зависимости от склада и товара — типовые встроенные инструменты 1С с этим не справлялись [16].

Практические этапы внедрения

1. Определить схему продаж по каждой площадке — FBS, FBO/FBW/FBY или их сочетание, поскольку от этого зависит, нужен ли обмен заказами в реальном времени или достаточно периодических отчётов.
2. Навести порядок в номенклатуре — каждому товару нужен уникальный артикул или штрихкод, по которому модуль сможет сопоставить позицию заказа площадки с позицией 1С.
3. Получить доступы к API — сгенерировать токен или API-ключ и Client-Id в личном кабинете площадки; для подключения интеграции обычно нужна учётная запись с правами администратора кабинета [19].
4. Настроить в 1С учёт комиссионной торговли — договор с комиссионером, документы передачи на комиссию, соответствие статусов заказов площадки и статусов документов 1С.
5. Выбрать способ получения заказов — регулярный опрос или API-уведомления, и продумать обработку ошибок и повторных запросов.
6. Настроить маркировку, если товар подлежит обязательной маркировке: привязку кодов к заказам и контроль сроков вывода из оборота.
7. Провести пилот на ограниченном ассортименте, прежде чем переводить весь каталог, — это позволяет выявить ошибки сопоставления номенклатуры и статусов до масштабирования [16].
8. Обучить сотрудников — склад, бухгалтерию и менеджеров по продажам, которые будут работать с новым интерфейсом обработки заказов внутри 1С.
9. Настроить регламент сверки — периодическую проверку соответствия остатков, заказов и отчётов комиссионера между 1С и личными кабинетами площадок.

Ограничения, ошибки и риски

• Игнорирование лимитов и ошибок API. Площадки ограничивают частоту запросов, а неправильно обработанные ошибки (таймауты, коды 4xx, некорректные ответы) могут привести к пропуску новых заказов или дублированию.
• Отсутствие уникальных артикулов. Без чёткого сопоставления номенклатуры интеграция начинает путать похожие товары, что ведёт к пересортице при отгрузке.
• Игнорирование сроков вывода кодов маркировки. Пропущенный срок вывода кода из оборота при FBS — это одновременно риск санкций от площадки и нарушение требований системы маркировки [12][13].
• Использование встроенного функционала «как есть» при сложной структуре бизнеса. Если у компании несколько юрлиц или складов, типовой функционал 1С может не покрыть потребность без доработки [16].
• Отсутствие пилота. Запуск обмена сразу на весь каталог без предварительного тестирования на ограниченном ассортименте увеличивает риск того, что ошибка сопоставления затронет сразу все заказы.
• Зависимость от одного разработчика модуля без резервного плана. Если сторонний модуль перестаёт обновляться после изменения API площадки, обмен может остановиться до момента миграции на другое решение [17].

Рекомендации по выбору решения

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

Как может помочь «Пятый фактор»

Основная сложность такой интеграции обычно не в самом факте вызова API, а в сопутствующих задачах: сопоставлении номенклатуры, настройке комиссионной схемы учёта, обработке ошибок и статусов, синхронизации маркировки и контроле обмена при росте числа заказов. Команда «Пятого фактора» может изучить существующий процесс продаж на маркетплейсах, оценить, достаточно ли встроенного функционала или готового модуля, и помочь с разработкой, доработкой или технической консультацией по интеграции 1С с Wildberries, Ozon и Яндекс Маркетом.

Чтобы обсудить задачу или получить консультацию, свяжитесь с командой «Пятого фактора» любым удобным способом.

Вывод

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

Источники

[1] dev.wildberries.ru — Обработка FBS-заказов, WB API — https://dev.wildberries.ru/knowledge-base/articles/019d49a4-0771-7571-aea9-11d5b597f34c/zakazy-fbs

[2] infostart.ru — Интеграция с маркетплейсами. Рекомендации для внедренцев — https://infostart.ru/1c/articles/2153866/

[3] dev.wildberries.ru — Swagger: заказы FBS (order OAS 3.0) — https://dev.wildberries.ru/en/swagger/orders-fbs

[4] docs.ozon.ru — Документация Ozon Seller API — https://docs.ozon.ru/api/seller

[5] dev.ozon.ru — Как работает Seller API: авторизация, настройка и первые шаги — https://dev.ozon.ru/start/297-Kak-rabotaet-Seller-API-avtorizatsiia-nastroika-i-pervye-shagi/

[6] dev.ozon.ru — Справочник методов Seller API для Ozon Логистики — https://dev.ozon.ru/start/448-Spravochnik-metodov-Seller-API-dlia-Ozon-logistiki/

[7] yandex.ru — Обработка FBS-заказов, партнёрский API Яндекс Маркета — https://yandex.ru/dev/market/partner-api/doc/ru/step-by-step/fbs

[8] yandex.ru — Партнёрский API Маркета для моделей продаж — https://yandex.ru/dev/market/partner-marketplace-common/

[9] cleverence.ru — Интеграция 1С с маркетплейсами: особенности учёта товаров — https://www.cleverence.ru/articles/auto-busines/integratsiya-1s-s-marketpleysami-osobennosti-raboty-i-uchet-tovarov/

[10] bobday.ru — Интеграция 1С с OZON, Wildberries, Яндекс Маркет — https://bobday.ru/blog/integraciya-1c-s-marketplaysami

[11] 1С-ИЖТИСИ — Интеграция 1С:УНФ с маркетплейсами: настройка комиссионной торговли

[12] markirovka.ru — Маркировка «Честный знак» на маркетплейсах: руководство для продавцов — https://markirovka.ru/community/best-practics/markirovka-chestnyy-znak-na-marketpleysakh-rukovodstvo-dlya-prodavtsov

[13] rdv-market.ru — Работа с маркировкой «Честный знак» на маркетплейсах — https://rdv-market.ru/press-center/blog/markirovka-chestnyy-znak-na-ozon-wb-yandex/

[14] glavbukh.ru — Маркированный товар на маркетплейсах (2026) — https://www.glavbukh.ru/art/391362-prodaja-markirovannogo-tovara-na-marketpleysah-oformlenie-uchet-v-2025-godu

[15] sovmestimo.1c.ru — CG: Интеграция с маркетплейсами (реестр «1С:Совместимо») — https://sovmestimo.1c.ru/catalog/29559/

[16] kt-team.ru — Кейс: единый шлюз 1С для Wildberries, Ozon и Яндекс Маркета — https://www.kt-team.ru/blog/unified-1c-gateway-wildberries-ozon-yandex-market-quick-start-accounting-order

[17] rarus.ru — Ответы на вопросы по интеграции 1С с Ozon, Wildberries и Яндекс Маркет — https://rarus.ru/publications/20250825-rabota-s-1c-unf-otvechaem-na-voprosy-po-integratsii-1c-s-ozon-wildberries-i-yandex-market-769011/

[18] koderline.ru — Обзор решений для интеграции 1С:УНФ, УТ и ERP с Ozon и Wildberries — https://www.koderline.ru/expert/narabotki/article-integratsiya-s-marketpleysami-ozon-wb-obzor-resheniy-dlya-1s-unf-ut-erp/

[19] wiseadvice-it.ru — Интеграция 1С:УНФ с маркетплейсами — https://wiseadvice-it.ru/o-kompanii/blog/articles/integratsiya-1s-unf-s-marketpleysami/