Складской учёт для маркетплейсов — FBO vs FBS в системе

Селлер торгует на Ozon, WB и Яндекс.Маркете. По одним товарам — FBO (хранение на складе маркетплейса), по другим — FBS (хранение у себя). В 1С УТ или УНФ учёт выглядит «как-нибудь»: остатки считаются дважды, заказы дублируются, возвраты теряются. Через полгода собственник не знает, сколько товара реально на складе и сколько денег застряло.

Что путают

FBO и FBS — это две разные физические локации товара:

• FBO — товар физически на складе Ozon/WB. Маркетплейс пакует и отгружает.
• FBS — товар на вашем складе. Вы пакуете, маркетплейс забирает курьером.

В учёте они должны быть отдельными локациями, не «общий остаток».

Минимальная модель в 1С

Для каждого маркетплейса заводятся склады:

• WB-FBO-Подольск
• WB-FBO-Хабаровск
• WB-FBS-собственный
• Ozon-FBO-Хоругвино
• Ozon-FBS-собственный
• Yandex-FBS-собственный

Один склад «свой» можно объединить для всех FBS, если физически он один.

Поступления и перемещения

• Закупка поступает на свой склад.
• Перемещение в FBO — отдельный документ. Кладовщик отгружает партию на Подольск WB, оформляет перемещение между складами.
• Списание у вас, поступление на FBO — два движения в одном документе.

До момента перемещения товар учитывается на собственном складе. Это даёт корректный остаток везде.

Отгрузки

Для каждого маркетплейса — отдельный документ «Реализация (маркетплейс)» с:

• Складом (FBO или FBS).
• Контрагентом «маркетплейс» (Ozon, WB, ЯМ).
• Ссылкой на заказ маркетплейса (orderId).
• Комиссией маркетплейса отдельной строкой.

На FBO документ создаётся по факту продажи (из выгрузки маркетплейса). На FBS — по заказу на сборку.

Возвраты — главная боль

Возврат может прийти:

• На склад FBO — увеличивает остаток FBO.
• На свой склад от FBS-покупателя — увеличивает свой остаток.
• На склад брака (если повреждён) — отдельный склад.

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

Сверка с маркетплейсом

Раз в неделю — сверка остатков на FBO с API маркетплейса. Расхождения бывают:

• Товар утерян/украден на складе маркетплейса — оформить претензию.
• Товар перемещён маркетплейсом между регионами — учесть.
• Брак, выявленный при упаковке — переоформить как возврат на склад брака.

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

Что автоматизировать в первую очередь

1. Выгрузка заказов с маркетплейсов в 1С (REST API → создание документов).
2. Выгрузка остатков FBO для сверки.
3. Расчёт комиссий по факту (а не по плану) — сильно влияет на маржу.
4. Отчёт «остаток по складам» с разбивкой FBO/FBS на дашборде.

Что не пытаться автоматизировать сразу

• Автозаказ пополнения FBO — модель спроса нужна более-менее точная, без неё накачаете склад мёртвым товаром.
• Цены — динамика цен на WB/Ozon вручную точнее, чем алгоритм без data science.
• Возвраты — слишком много кейсов, ручная обработка надёжнее.

Вывод

FBO и FBS требуют отдельных складов в учётной системе, даже если физически склад один. Без разделения остатки врут, комиссии теряются, возвраты не учитываются. Базовый минимум — склады по маркетплейсу/региону, отдельный «возвраты/брак», еженедельная сверка с API. Без этого через полгода — каша.