Интеграция с маркетплейсами: как связать 1С, склад и сайт с Ozon и Wildberries

Одна продажа меняет обещание во всех каналах

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

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

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

Модель продажи определяет смысл остатка

Начать стоит с места хранения товара. При работе со своего склада продавец распоряжается запасом, который может участвовать сразу в нескольких каналах. При передаче партии площадке это уже другой запас. В сравнении моделей Wildberries «Склад WB» (FBW) отделён от «Маркетплейса» (FBS), где сборка остаётся продавцу, а доставка — площадке. Для интеграции это различие важнее совпадения артикула: товар на другом складе нельзя автоматически обещать к той же отгрузке.

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

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

Одинаковое название не связывает товары

Системам нужна устойчивая связь позиций. Название подходит для чтения, но может измениться после редакторской правки и не обязано быть уникальным для всех вариантов товара. Поэтому я выбираю отдельную таблицу соответствий, где связаны внутренний артикул, конкретное исполнение и обозначения площадок, а не сопоставление по похожим словам: ошибка здесь превращается в неверный остаток и отгрузку другого изделия. В официальном FAQ Ozon Seller API для связи товара названы offer_id и product_id. Читателю не требуется запоминать программные имена. Их стоит оставить в таблице, которую подготовит исполнитель, чтобы после переименования карточки связь с учётной позицией сохранялась и сотрудник мог найти причину расхождения.

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

Что вычитать из физического количества

Доступный запас отличается от числа на полке. Часть товара уже может относиться к принятым заказам, часть — ожидать осмотра после возврата, а часть — находиться на складе, который не исполняет выбранную модель доставки. Сначала склад и продажи договариваются, какое количество компания готова обещать, затем это правило переносится в обмен, чтобы автоматизация передавала осмысленное предложение, а не просто последнюю найденную цифру. Резерв связывает запас с обязательством. Если заказ поступил с площадки и принят к работе, соответствующее количество нужно учесть до следующего обещания другому покупателю. Чем реже обновляются каналы, тем больше времени сохраняется риск пересечения, поэтому период передачи выбирают по объёму продаж и возможностям систем, а не называют мгновенным без демонстрации.

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

Участники приёмки используют небольшой набор тестовых позиций. Сначала меняют физическое количество, затем создают заказ и отдельно разбирают отмену. Такой опыт показывает смысл передаваемого числа на каждом этапе; разработчик объясняет расчёт, а сотрудник склада подтверждает, что по нему действительно можно принимать новые заказы.

Цена меняется по одному описанному порядку

Одновременное редактирование цены создаёт гонку. Менеджер исправляет сумму в кабинете площадки, а очередная передача из учёта возвращает старое значение, после чего оба участника уверены, что система теряет правки. Лучше заранее назначить место изменения для каждого вида цены и описать исключения, чем разрешить редактирование во всех окнах без понимания, какая запись попадёт в следующую отправку. Базовая цена и участие в акции могут относиться к разным действиям. Для руководителя полезно видеть, какую сумму отправляет подключение и какую сумму получает покупатель после правил площадки. Эти сведения обсуждают с ответственным за продажи: интеграция не должна молча стирать решение менеджера об акции или создавать скидку, которую компания не учла при расчёте расходов.

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

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

Заказ возвращается к учёту и сотруднику

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

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

Повтор — ожидаемая ситуация. Его стоит показать до запуска, пока тестовая запись не превратилась во вторую реальную отгрузку.

Отказ требует понятного продолжения

Сообщение об ошибке полезно только с действием. В FAQ Ozon встречается ошибка PRODUCT_IS_NOT_CREATED: товар ещё не создан. Другая ошибка NOT_PASS_MODERATION относится к непройденной модерации. Сотруднику нужен разбор тех ошибок, которые показывает подключение: какую запись открыть, что исправить и когда повторить передачу, поскольку новый запуск обмена без изменения карточки или её состояния лишь воспроизведёт прежнее препятствие.

Ошибки разделяют по ответственности. Неизвестный товар разбирает менеджер каталога, проблему доступа — ответственный за подключение, а расхождение количества требует участия склада. Общий журнал с одной красной строкой заставит сотрудников снова просить разработчика переводить каждое сообщение, поэтому рядом с технической причиной полезнее дать название товара, площадку и рабочее объяснение следующего действия.

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

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

Готовое подключение тоже имеет границы

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

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

Один успешный товар — начало. Для запуска нужны и разные варианты, и отсутствующий остаток, и отказ, потому что именно на различиях обнаруживаются границы готового обмена.

В инструкции первой продажи Wildberries остатки можно обновлять через раздел «Управление остатками» или API. Название способа не определяет качество результата: руководителю полезнее увидеть, как сохраняется количество после заказа и исправляется отказ, чем выбирать автоматическое подключение лишь по наличию знакомого сокращения в предложении.

Составьте паспорт каждого обмена

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

Образец записи

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

Паспорт даёт предмет для оценки. По нему удобно обсудить интеграцию со ШТАБ ИТ, приложив версию 1С, выбранные модели продаж и пример товарной таблицы.

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