Как эффективно вести посерийный учет товаров при работе с маркетплейсами Ozon и Wildberries?

← К списку

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

Мы проанализируем основные схемы работы с маркетплейсами — FBO (Fulfillment by Operator) и FBS (Fulfillment by Seller) — и рассмотрим, как каждая из них влияет на возможность ведения детального учета. Также мы уделим внимание обязательной маркировке товаров через систему «Честный ЗНАК» и ее влиянию на наши учетные процессы.

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

Начнем с наиболее управляемой схемы — FBS (Fulfillment by Seller). Эта модель подразумевает, что вы, как продавец, самостоятельно храните товар на своем складе, упаковываете его под каждый конкретный заказ и отвозите в пункт выдачи маркетплейса или передаете курьеру. Именно здесь кроются максимальные возможности для сохранения полного контроля над посерийным учетом.

Рассмотрим подробнее преимущества FBS:

Полный контроль над товаром: Поскольку товар находится на вашем складе до момента отгрузки конкретному покупателю, вы полностью контролируете его перемещение. Это позволяет нам в 1С четко фиксировать, какая именно серия товара была отгружена по каждому заказу.
Учет сроков годности: При FBS вы сами управляете остатками и можете отслеживать сроки годности каждой единицы товара. Это критически важно для скоропортящейся продукции или товаров с ограниченным сроком реализации. Вы можете настроить правила сборки заказов так, чтобы в первую очередь отгружались товары с более коротким сроком годности, избегая просрочки.
Работа с маркировкой «Честный ЗНАК»: В схеме FBS вы легко можете указывать коды маркировки для каждого отправления. Маркетплейсы, такие как Ozon и Wildberries, предоставляют функционал для ввода кодов маркировки (например, в статусах «Ожидает сборки» или «Готов к отгрузке» на Ozon). Мы, как селлер, остаемся ответственными за передачу этих данных и вывод товаров из оборота после продажи. В 1С это реализуется через документы РеализацияТоваровУслуг или ОтгрузкаТоваров с обязательным указанием кодов маркировки и дальнейшей передачей данных через систему электронного документооборота (ЭДО).
Гибкость при возвратах: Если покупатель отказывается от товара, он возвращается на ваш склад. Вы можете принять его обратно на учет, снова проверив серию и срок годности, и при необходимости выставить на продажу или утилизировать.

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

При поступлении товаров на склад мы фиксируем их серии с помощью документа ПриходныйОрдерНаТовары или ПоступлениеТоваровУслуг.
При сборке заказа маркетплейса мы указываем конкретные серии, которые отбираются со склада. Это отражается в ЗаказКлиента и РеализацияТоваровУслуг.

В случае, если собственных складских мощностей недостаточно, мы можем воспользоваться услугами 3PL-операторов (Third-Party Logistics). Это сторонние компании, которые берут на себя функции хранения, комплектации и доставки. Важное отличие от FBO маркетплейса заключается в том, что 3PL-оператор действует по вашим прямым распоряжениям. Вы передаете ему заказы, а он комплектует их из ваших товаров, учитывая серии и сроки годности. Это позволяет сохранить контроль над посерийным учетом, как если бы товар находился на вашем собственном складе.

Таким образом, схема FBS (включая работу через 3PL-операторов) является наиболее предпочтительной для тех, кто хочет иметь полный контроль над посерийным учетом и сроками годности своих товаров.

Учет товаров по схеме FBO: Сложности и возможные обходные пути

Схема FBO (Fulfillment by Operator) подразумевает, что вы отгружаете партию товара на склад маркетплейса, а он уже самостоятельно занимается хранением, комплектацией, упаковкой и доставкой заказов конечным покупателям. Здесь мы сталкиваемся с куда большими сложностями в поддержании детального посерийного учета.

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

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

Схемы работы с маркировкой и «Честный ЗНАК» при FBO

Несмотря на общие сложности с посерийным учетом, обязательная маркировка товаров через систему «Честный ЗНАК» вносит свои коррективы. Даже при FBO вы, как селлер, несете ответственность за передачу сведений о кодах маркировки. Рассмотрим два основных сценария:

Продавец остается собственником: Маркетплейс при приемке товара проверяет коды маркировки. Вы самостоятельно регистрируете все движения товара в «Честном ЗНАКе» и выводите товары из оборота после продажи. Это требует от нас внимательного отслеживания отчетов маркетплейса и оперативного реагирования.
Товар переходит в собственность маркетплейса: В «Честном ЗНАКе» фиксируется передача права собственности и кодов маркировки маркетплейсу (например, через УПД-2). В этом случае маркетплейс берет на себя дальнейший учет и вывод товаров из оборота. Например, Ozon при приеме маркированных товаров по FBO использует данные из акта приема для формирования УПД-2 с кодами маркировки, который вы должны подписать. Это значительно упрощает нашу задачу по выводу из оборота, но не решает проблему внутреннего посерийного учета.

В обоих случаях мы обязаны передавать данные о кодах маркировки маркетплейсу. Отсутствие или повреждение кода Data Matrix может привести к непринятию товара и штрафам. В 1С мы оформляем отгрузку маркированного товара на склад маркетплейса с указанием всех кодов маркировки в документе ПередачаТоваровНаКомиссию или РеализацияТоваровУслуг, а затем формируем УПД через ЭДО.

Моделирование логистики маркетплейса в 1С (сложный и ресурсоемкий подход)

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

Разберем по шагам, как это могло бы выглядеть:

Создание дополнительного склада: Мы создаем в 1С дополнительный склад, например, «Наш склад на территории Ozon» или «Склад Wildberries FBO».
Перемещение товаров: При отгрузке партии товаров на маркетплейс, мы оформляем внутреннее перемещение в 1С с нашего основного склада на этот «виртуальный» склад маркетплейса. Документ ПеремещениеТоваров позволяет нам отследить, какие серии уехали на маркетплейс.

Смена серий на «складе маркетплейса»: Здесь начинается самое сложное. Когда маркетплейс продает товар, он присылает отчеты, где обычно указан номер заказа конечного покупателя, но не ваша внутренняя серия. Нам придется пытаться сопоставить эти продажи с нашими сериями, которые мы отправили. Предлагается вариант «смены серий», где старая серия трансформируется в новую, например, СтараяСерия + НомерЗаказаКлиента. Это может выглядеть так:


// Пример концептуальной логики смены серий в 1С
Для Каждого СтрокаОтчета Из ОтчетМаркетплейса Цикл
    Если СтрокаОтчета.Количество > 0 Тогда
        // Находим товары на "складе маркетплейса"
        Запрос = Новый Запрос;
        Запрос.Текст = "ВЫБРАТЬ ПЕРВЫЕ 1
                       |    ОстаткиСерий.Серия КАК Серия,
                       |    ОстаткиСерий.Номенклатура КАК Номенклатура
                       |ИЗ
                       |    РегистрНакопления.ОстаткиТоваровПоСериям КАК ОстаткиСерий
                       |ГДЕ
                       |    ОстаткиСерий.Склад = &СкладМаркетплейса
                       |    И ОстаткиСерий.Номенклатура = &Номенклатура
                       |    И ОстаткиСерий.ВНаличии > 0
                       |УПОРЯДОЧИТЬ ПО
                       |    ОстаткиСерий.СрокГодности Возр"; // Например, выбираем по сроку годности
        Запрос.УстановитьПараметр("СкладМаркетплейса", СсылкаНаСкладМаркетплейса);
        Запрос.УстановитьПараметр("Номенклатура", СтрокаОтчета.Номенклатура);

        РезультатЗапроса = Запрос.Выполнить().Выбрать();
        Если РезультатЗапроса.Следующий() Тогда
            СтараяСерия = РезультатЗапроса.Серия;
            НоваяСерия = СтараяСерия + "_" + СтрокаОтчета.НомерЗаказаКлиента;

            // Здесь должна быть логика создания документа "СменаСерий" или аналогичного
            // для отражения изменения серии в учетной системе
            // Это очень трудоемко и требует ручной работы или сложной автоматизации
            Сообщить("Серия " + СтараяСерия + " изменена на " + НоваяСерия + " для заказа " + СтрокаОтчета.НомерЗаказаКлиента);
        КонецЕсли;
    КонецЕсли;
КонецЦикла;

Создание такой "новой" серии позволит нам хоть как-то привязать проданный товар к конкретному заказу, но это не будет истинным посерийным учетом в привычном смысле.

Передача на комиссию с новыми сериями: После «смены серий» мы оформляем передачу на комиссию товара с этими новыми «сериями-заказами» с нашего «склада маркетплейса» по договору комиссии с маркетплейсом.
Обработка возвратов: При возврате или отказе покупателя, мы оприходуем товар на «склад маркетплейса» с указанием соответствующей «серии-заказа». В отчетах маркетплейса могут быть разные строки для возвратов (отказ при приемке, возврат через несколько дней), что усложняет сопоставление.
Дальнейшее движение возвращенных товаров: В зависимости от судьбы возвращенного товара (например, если он стал FBO после отказа клиента на FBS), мы либо перемещаем его на свой основной склад (возможно, с обратной сменой серий на изначальные), либо передаем на комиссию по другому договору.

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

Кроме того, современные конфигурации 1С не рассчитаны на «посмертный учет», когда данные приходится вносить задним числом на основании отчетов маркетплейсов, которые могут приходить раз в неделю или даже месяц. Это приводит к рассинхронизации данных и сложностям в оперативном управлении.

Ключевые аспекты, которые необходимо учитывать

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

Обязательная маркировка и «Честный ЗНАК»

Государственные требования по обязательной маркировке через систему «Честный ЗНАК» являются неотъемлемой частью работы с маркетплейсами. Мы, как селлеры, несем юридическую ответственность за нарушения маркировки. Маркетплейсы могут передавать информацию о недобросовестных продавцах в Минпромторг.

Процесс передачи кодов: Необходимо зарегистрироваться в «Честном ЗНАКе», оформлять документы через ЭДО, указывая коды маркировки в накладных, и передавать эти данные маркетплейсу для проверки.
Формат кодов: Код маркировки должен соответствовать формату GS1 DataMatrix, содержать идентификаторы применения, разделители, код товара, серийный номер и крипточасть. В 1С это реализуется через специализированные модули или встроенные функции работы с маркировкой.
Штрафы: За отсутствие или повреждение кода Data Matrix на товаре маркетплейс может не принять продукцию, а вам грозят серьезные штрафы.

Учет сроков годности

Ответственность за отслеживание сроков годности товаров, особенно при работе по FBO, с февраля 2024 года Ozon переложил на продавцов. Нам необходимо самостоятельно контролировать эти данные в личном кабинете маркетплейса. Для FBO существуют минимальные требования к остаточному сроку годности (например, 70% от общего срока для Ozon, 50% для Wildberries).

Если товар с истекшим сроком годности не выкуплен покупателем (особенно на Wildberries по FBS), он будет утилизирован за наш счет. Это еще раз подчеркивает важность тщательного учета сроков годности, который гораздо проще реализовать при схеме FBS.

Интеграция с 1С и автоматизация учета

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

Документооборот: Основные документы для учета в 1С — это УниверсальныйПередаточныйДокумент (УПД) при отгрузке и ОтчетКомиссионераОПродажах (или ОтчетАгента) для отражения выручки и расчетов с маркетплейсом.
Проблемы с «посмертным учетом»: Как мы уже упоминали, сложность в том, что отчеты маркетплейсов приходят с задержкой, что затрудняет оперативный учет в 1С. Нам приходится вносить данные задним числом, что может приводить к расхождениям.
Готовые решения: На рынке существуют специализированные модули и сервисы для 1С, предназначенные для интеграции с маркетплейсами. Они облегчают работу с отчетами комиссионера, синхронизацию остатков и цен, а также обработку заказов. При выборе такого решения, внимательно изучайте его функционал по работе с сериями и маркировкой.

Подводя итог, мы видим, что полный и надежный посерийный учет с контролем сроков годности наиболее эффективно реализуется при работе по схеме FBS или с использованием 3PL-операторов. Схема FBO значительно усложняет этот процесс, делая прямой посерийный учет практически невозможным из-за потери контроля над физическим товаром. Однако, даже в FBO, обязательная маркировка через «Честный ЗНАК» требует от нас внимательного отслеживания и передачи кодов маркировки, что должно быть автоматизировано через 1С и ЭДО.

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

← К списку