Раздельные корзины для продавцов на маркетплейсе 1С-Битрикс

Раздельные корзины в Битрикс: где ломается заказ на маркетплейсе

Штатный магазин 1С-Битрикс собирает всё в один заказ: корзина одна, оплата одна, статус один. Пока товары продаёт один поставщик, схема работает. На маркетплейсе в корзине оказываются позиции разных продавцов — и штатная логика превращается в источник ошибок оформления заказа.

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

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

Ошибки оформления заказа всплывают позже — два счёта на одну корзину, повторное списание при пересборке, потерянная позиция после правки состава. Каждую такую ситуацию менеджер разруливает руками, и каждая съедает время покупателя.

Раздельные корзины в Битрикс закрывают это на уровне архитектуры: оформление заказа маркетплейса дробится по продавцам ещё на входе, а не правится после. Разбираем, как это устроено и на что смотреть при внедрении.

Что меняется после внедрения: скорость сборки и меньше отказов

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

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

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

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

Один заказ или корзина продавца: сравнение подходов

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

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

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

Как проходит внедрение: аудит, схема, настройка, приёмка

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

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

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

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

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

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

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

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

Конфигурации, схемы данных и регламенты обработки заказов

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

• Конфигурация модуля оформления — какие корзины закреплены за продавцами, правила консолидации позиций в один заказ, ограничения по доставке и минимальной сумме на каждую часть.
• Схема данных заказа — сущности, в которых хранится разделение по продавцам, связи позиций, платежей и отгрузок, чтобы отчётность по частям сходилась с итогом.
• Шаблоны статусов и писем — логика переходов отдельно для каждой части заказа и уведомления покупателю и продавцам на каждом шаге.
• Инструкция для менеджеров — как разобрать заказ с несколькими продавцами, что делать при отмене или возврате одной позиции, где смотреть причину расхождения.
• Карта интеграций — что и в каком направлении обменивается данными с учётной системой, складом, платежами и доставкой, включая точки отказа обмена.
• Регламенты обработки — расписание обмена, правила повторной отправки при сбое, порядок ручного вмешательства и границы, за которыми подключаемся мы.
• Набор тестовых сценариев — заказы с разными комбинациями продавцов, частичные отмены и возвраты; на нём проверяют каждую правку после релиза.

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

Кейс маркетплейса: меньше ошибок в заказах и быстрее сборка

До: одна корзина на всех продавцов

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

Что изменили

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

Что стало по метрикам

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

Что делать, если оформление заказа уже настроено по старой схеме

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

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

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

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

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

Оплата, доставка и статусы заказов: частые технические сомнения

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

Можно ли провести оплату одной операцией, а не несколькими списаниями?

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

Что покупатель видит по статусам, если части заказа едут отдельно?

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

Как части заказа попадают в учётную систему?

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

Обсудим задачу: вернёмся с оценкой и планом работ

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

На разбор вы получите:

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

Опишите задачу в удобной форме — вернёмся с оценкой объёма и планом внедрения, укажем риски и этапы, на которых понадобится доступ к административной части и тестовому стенду.