Одежда и обувь: маркетплейс

Площадка с продавцами: кабинеты, комиссии, выплаты, разделение заказов между поставщиками и правила модерации. Технически это уже не магазин, а платформа.

Категория «Одежда и обувь» добавляет к этому свою специфику: Каталог держится на матрице «модель × цвет × размер»: без размерных сеток, таблиц соответствия и групповых карточек товаров сотни SKU превращаются в ручную работу контент-менеджера.

Одежда, обувь и текстиль входят в перечень обязательной маркировки ГИС МТ «Честный знак»: код маркировки нужно получить, нанести на товар, вывести из оборота при продаже и передать в ОФД вместе с чеком.

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

Оплата проектируется под формат «маркетплейс»: обычно в одном магазине соседствуют несколько способов — карты, СБП, оплата по счёту, рассрочка или автосписание. Под каждый способ нужен корректный чек ОФД по 54-ФЗ, включая возвраты и частичные отмены.

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

Главная метрика — доля возвратов. Примерка, обмен размера и возврат без брака требуют отдельного сценария: заявка в личном кабинете, обратная отправка, автоматический возврат в 1С и в отчётность.

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

Типовой контур: 1С:УТ или «МойСклад» по номенклатуре и остаткам, СДЭК и Boxberry по доставке, Wildberries и Ozon по FBS-отгрузкам, эквайринг и СБП по оплате.

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

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

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

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

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