Налаштування роздільних кошиків на маркетплейсі 1С-Бітрікс

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
Пропоновані послуги
Показано 1 з 1 послугУсі 1626 послуг
Налаштування роздільних кошиків на маркетплейсі 1С-Бітрікс
Проста
~1 робочий день
Часті питання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.png
    Розробка сайту компанії B2B ADVANCE
    1262
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Розробка веб-сайту для компанії ФІКСПЕР
    851
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    585
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    751
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    657
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    989

Налаштування окремих кошиків за продавцями на маркетплейсі 1С-Bitrix

Коли покупець додає товари від різних продавців, виникає питання: як оформити замовлення? Єдине замовлення (як на Wildberries) або кілька окремих (як на Авіто)? Обидва варіанти реалізуються на Bitrix, але вимагають різних підходів.

Варіант 1: Візуально окремі кошики, одна оплата

Кошик b_sale_basket єдиний у БД, але інтерфейс групує позиції за UF_VENDOR_ID товару. Покупець бачить розділи «Продавець А» та «Продавець Б» з окремими сумами. Оплата — один платіж загальної суми.

При оформленні створюється один b_sale_order, але в фоні генеруються суб-замовлення для кожного продавця (таблиця mp_sub_orders). Продавці бачать тільки свої суб-замовлення.

Реалізація візуального розділення в шаблоні компонента sale.basket.basket: в template.php групуємо $arResult['ITEMS'] за UF_VENDOR_ID перед відображенням:

$itemsByVendor = [];
foreach ($arResult['ITEMS'] as $item) {
    $vendorId = CIBlockElement::GetByID($item['PRODUCT_ID'])->GetNext()['UF_VENDOR_ID'];
    $itemsByVendor[$vendorId][] = $item;
}

Переваги: один платіж, кращий UX для покупця. Недоліки: складніше розбивати суми при частковій скасуванні.

Варіант 2: Окремі замовлення для кожного продавця

При оформленні система створює окреме b_sale_order на кожного продавця. Покупець отримує кілька підтвердження замовлення та здійснює кілька платежів (або один через агрегатор з розщепленням).

Реалізація через користувацький обробник оформлення замовлення: стандартний флоу CSaleOrder::Add() замінюється користувацьким, який розбиває кошик за UF_VENDOR_ID та створює кілька замовлень у циклі.

Переваги: кожне замовлення незалежне, простіше управляти статусами та поверненнями. Недоліки: незручно для покупця при великій кількості продавців.

Доставка при окремих кошиках

При єдиному кошику з кількома продавцями доставка ускладнюється: у кожного продавця можуть бути свої способи та вартість. Можливі підходи:

  • Єдина доставка силами маркетплейсу (платформа агрегує всі товари)
  • Окремий вибір доставки для кожного продавця (покупець вибирає окремо)
  • Самовивіз із точки маркетплейсу (спільної)

Налаштування доставки під конкретну схему — окрема задача.

Терміни

Візуальне розділення кошика без змін логіки замовлень — 3–5 днів. Повне розділення з створенням окремих замовлень — 1–2 тижні. З користувацькою логікою доставки за продавцями — до 3 тижнів.