Налаштування Click & Collect у 1С-Бітрікс: резервування та самовивіз

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

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

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

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

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1358
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947
  • 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
    694
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    830
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    732
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1075

Типова проблема: покупець оформлює самовивіз, приїжджає в магазин, а товару на полиці немає. Причина — не налаштована жорстка прив'язка до складів і не перевіряється реальна наявність перед резервуванням. Ми такі ситуації виключаємо через правильну конфігурацію Click & Collect. Наш досвід — понад 50 проєктів на Бітрікс, сертифіковані інженери з гарантією результату.

Click & Collect (онлайн-замовлення з самовивозом) — один із найзатребуваніших сценаріїв у ритейлі, особливо після пандемії. Але без коректної роботи з залишками та резервуванням він приносить більше проблем, ніж користі. Покупець обирає точку, де товару немає, або дві людини одночасно замовляють останню одиницю — і хтось іде ні з чим розчарований. Правильна реалізація на 1С-Бітрікс вирішує ці завдання на рівні архітектури: жорстка прив'язка точок до складів, перевірка залишків у кошику перед резервуванням, резервування при оформленні замовлення. Нижче — як це працює на практиці з прикладами коду.

Чому важливо прив'язувати точки самовивозу до складів?

Кожна точка самовивозу має бути жорстко прив'язана до конкретного складу через XML_ID. Тільки так система розуміє, які залишки показувати. Без цієї прив'язки самовивіз перетворюється на лотерею. Ми використовуємо стандартні таблиці Бітрікс: b_catalog_store та b_catalog_store_product. Приклад запиту для перевірки залишків:

SELECT s.ID, s.TITLE, s.ADDRESS, sp.AMOUNT
FROM b_catalog_store s
JOIN b_catalog_store_product sp ON sp.STORE_ID = s.ID
WHERE sp.PRODUCT_ID = ? AND s.ACTIVE = 'Y' AND sp.AMOUNT > 0
ORDER BY s.SORT ASC;

Документація 1С-Бітрікс: управління складами

Як додати службу доставки «Самовивіз»

В адміністративній панелі: Магазин → Доставка → Додати службу доставки → Тип: Самовивіз. Вкажіть найменування, активуйте її, налаштуйте вартість (зазвичай нуль). Програмне створення через API дає більшу гнучкість — можна умовні правила та інтеграцію з 1С:

\Bitrix\Main\Loader::includeModule('sale');

$deliveryService = \Bitrix\Sale\Delivery\Services\Manager::getList([
    'filter' => ['CODE' => 'self_pickup'],
])->fetch();

if (!$deliveryService) {
    \Bitrix\Sale\Delivery\Services\Manager::add([
        'NAME'       => 'Самовивіз з магазину',
        'CODE'       => 'self_pickup',
        'ACTIVE'     => 'Y',
        'CLASS_NAME' => '\Bitrix\Sale\Delivery\Services\Base',
        'CURRENCY'   => 'RUB',
        'PRICE'      => 0,
    ]);
}

Як обрати точку самовивозу в кошику?

У шаблоні компонента sale.order.ajax виводимо список точок з перевіркою залишків. Приклад:

// Отримуємо активні склади з наявністю товарів з кошика
$basketItems = $order->getBasket();
$productIds = [];
foreach ($basketItems as $item) {
    $productIds[] = $item->getProductId();
}

$storesResult = \Bitrix\Catalog\StoreTable::getList([
    'filter' => ['ACTIVE' => 'Y'],
    'select' => ['ID', 'TITLE', 'ADDRESS', 'GPS_N', 'GPS_S'],
    'order'  => ['SORT' => 'ASC'],
]);

$availableStores = [];
while ($store = $storesResult->fetch()) {
    $allAvailable = true;
    foreach ($productIds as $productId) {
        $stockResult = \Bitrix\Catalog\StoreProductTable::getList([
            'filter' => ['PRODUCT_ID' => $productId, 'STORE_ID' => $store['ID']],
            'select' => ['AMOUNT'],
        ])->fetch();

        if (!$stockResult || $stockResult['AMOUNT'] < $basketItems->getQuantityByProductId($productId)) {
            $allAvailable = false;
            break;
        }
    }

    if ($allAvailable) {
        $availableStores[] = $store;
    }
}

Як налаштувати резервування: покрокова інструкція

Резервування — критичний етап, від якого залежить надійність Click & Collect. При неправильній реалізації втрачаються товари та виникають конфлікти з покупцями.

  1. Створіть користувацьку властивість замовлення PICKUP_STORE_ID через Магазин → Налаштування → Властивості замовлення. Тип — список або рядок з посиланням на таблицю складів.
  2. Додайте обробник події OnSaleOrderBeforeSaved. У ньому отримайте ID вибраного складу з властивості замовлення та перевірте залишки ще раз перед бронюванням.
  3. Викличте резервування для кожного товару кошика через \Bitrix\Catalog\StoreProductTable::reserveProduct. Переконайтеся, що функція повертає успіх перед збереженням замовлення.

Приклад обробника:

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'sale', 'OnSaleOrderBeforeSaved',
    function (\Bitrix\Main\Event $event) {
        $order = $event->getParameter('ENTITY');
        $pickupStoreId = $order->getPropertyCollection()
            ->getItemByOrderPropertyCode('PICKUP_STORE_ID')
            ?->getValue();

        if (!$pickupStoreId) return;

        foreach ($order->getBasket() as $basketItem) {
            \Bitrix\Catalog\StoreProductTable::reserveProduct(
                $basketItem->getProductId(),
                (int)$pickupStoreId,
                $basketItem->getQuantity(),
                $order->getId()
            );
        }
    }
);
Деталі роботи обробника Обробник спрацьовує до збереження замовлення — резервування відбувається атомарно. Якщо резервувати не вдалося (наприклад, товару немає на складі), замовлення не зберігається, а користувач бачить помилку. Це захищає від подвійних продажів.

Сповіщення та статуси замовлень самовивозу

Після вибору точки та резервування товару потрібно організувати сповіщення покупцеві. Коли замовлення перейде в статус «Готовий до видачі» (зазвичай після обробки в 1С), система надсилає email та SMS на номер з профілю: адреса магазину, години роботи, що взяти з собою. Для постійних клієнтів рекомендується особистий кабінет з відстеженням статусу в реальному часі. Реалізація через події OnSaleOrderStatusChange та шаблони листів. Наш досвід показує, що правильні сповіщення знижують кількість неявок на 20–30%.

Що входить в роботу?

Етап Тривалість Результат
Аналітика 0.5 дня Схема складів, список точок
Налаштування служби доставки 1 день Готова служба самовивозу
Розробка вибору точки 1–2 дня Виведення точок з залишками в кошику
Резервування 1 день Обробник OnSaleOrderBeforeSaved
Сповіщення та статуси 1 день Email та SMS при готовності до видачі
Інтеграція з 1С (опціонально) 2–3 дні Обмін залишками по CommerceML
Тестування та документація 1 день Інструкція для менеджерів

Під ключ: від 7 робочих днів. Гарантія 6 місяців на доопрацювання. Сертифікат 1С-Бітрікс.

Порівняння: вбудований механізм vs кастомне рішення

Параметр Вбудований самовивіз Кастомне рішення з HL-блоками
Гнучкість Фіксована логіка Повна свобода
Швидкість впровадження 1–2 дні 3–5 днів
Синхронізація з 1С Через склади Будь-яка ERP

Кастомне рішення краще вбудованого за гнучкістю в 2–3 рази, але вимагає більше часу та ресурсів на реалізацію.

Для розрахунку вартості та термінів вашого проєкту — зв'яжіться з нами. Замовте консультацію з налаштування Click & Collect.

Додаткова інформація: документація по службам доставки.

Як налаштування кошика 1С-Бітрікс вирішує проблему втрати конверсії

Ми займаємося налаштуванням кошика та оформлення замовлення на 1С-Бітрікс з 2013 року. За цей час зіткнулися з типовою проблемою: штатний sale.order.ajax втрачає на кожному кроці 10–15% покупців. Три кроки — і третина тих, хто вже додав товар, іде. Не тому що передумали — інтерфейс спотикається.

sale.order.ajax видає 500-ку, якщо не налаштований хоча б один обробник доставки. Зависає на 15 секунд при розрахунку НПП — запит синхронний, без таймауту. Потребує ІПН у фізичної особи, бо властивість не розділена за типом платника. Кожен такий кейс — прямі втрати, які система не компенсує.

Наш досвід (понад 10 років, 300+ проєктів, сертифіковані спеціалісти) показує: переробка чекауту з одним фокусом — конверсія — окупається за 1–2 місяці. Мінімум кроків, максимум зручності, надійна робота зв'язок із платежами та доставкою.

Чому однокроковий чекаут збільшує конверсію?

Всі поля на одній сторінці. Логічне групування, жодних зайвих переходів:

  • Контактні дані — ім'я, телефон, email. Три поля. Не п'ять, не десять, не «вкажіть дату народження для програми лояльності».
  • Доставка — вибрав місто → побачив способи з цінами та термінами. AJAX-розрахунок через API НПП, Boxberry, Укрпошти. Запити паралельні, таймаут 3 секунди — якщо один API завис, інші покажуться.
  • Оплата — способи фільтруються за вибраною доставкою. Післяплата при самовивозі? Не показуємо.
  • Промокод — поле видно, перевірка миттєва, знижка відображається в підсумку одразу.
  • Підсумок — динамічний перерахунок за будь-якої зміни. Змінив кількість → сума → вартість доставки → підсумок. Без перезавантаження.

Під капотом:

  • Повний AJAX — жодного перезавантаження. Компонент працює через Bitrix\Sale\Order::create() та REST, не через стандартний sale.order.ajax.
  • Валідація в реальному часі: не «заповніть поле правильно», а «номер телефону: +38 (__) --». Маска inputmask + серверна перевірка.
  • Збереження даних при випадковому відході — sessionStorage зберігає введене, при поверненні все на місці.
  • Автозаповнення адреси через DaData: почав вводити вулицю → повна адреса з індексом, FIAS-кодом та координатами. Менше помилок з боку кур'єрської.
  • Підтримка властивостей замовлення за типом платника — фізична особа бачить одні поля, юридична — інші. Перемикач у формі.

Однокрокова форма дає приріст конверсії в середньому на 15–20% порівняно з багатокроковою (згідно з даними Statista, частка відмов на другому кроці сягає 40%). Джерело: Statista, дослідження чекауту в e-commerce.

Як відновити покинуті кошики?

Збереження. Авторизовані — кошик у b_sale_basket, доступний з будь-якого пристрою. Гості — cookie з TTL 30 днів. FUSER_ID прив'язаний до cookie, кошик не пропаде через годину. Синхронізація: додав з телефону, оформив з ноутбука — кошик єдиний.

Повернення. Email-серія: 3 листи. Через 1 годину — нагадування. Через 24 години — «ваш товар закінчується». Через 72 години — персональний промокод на 5–10%. Реалізація через sale.basketcomponent + CEvent::Send() з відкладеною відправкою через агенти. Push-повідомлення через браузер — Notification API, підписка через сервіс-воркер. Ретаргетинг — дані про кошик йдуть у Google Ads через eCommerce-події.

Аналітика відмов. На якому кроці йдуть? Якщо на виборі доставки — ціна шокує. Якщо на оплаті — карта відхиляється, 3D-Secure не проходить. Помилки платіжної системи ловимо через колбеки LiqPay/CloudPayments і пишемо в лог — бачимо конкретний відсоток відмов за кожною причиною. Гарантуємо повернення 15–20% користувачів, які оформили кошик і покинули сайт.

Гостьове замовлення: убити обов'язкову реєстрацію

«Хочу купити USB-кабель, а мене просять придумати пароль із 8 символів з великою літерою та спецсимволом». Обов'язкова реєстрація вбиває 25–30% конверсії на дрібних замовленнях.

  • Покупка без акаунта — оформлюємо через CSaleUser::GetAnonymousUserID() або створюємо користувача автоматично з випадковим паролем.
  • Після оформлення — лист з даними для входу. Хоче — активує акаунт, не хоче — і так отримає замовлення.
  • Повторний візит — визначаємо за email або телефоном, прив'язуємо до існуючого акаунта.
  • Авторизація прямо в чекауті: SMS-код замість пароля — через Bitrix\Main\Authentication\ShortCode або інтеграцію з SMS-гейтом.

Крос-сел: допродажі, які не дратують

У кошику

Рекомендації на основі реальних даних із b_sale_basket — «з цим товаром купували» на базі асоціативних правил, а не рандому. Прив'язка через властивість інфоблоку PROPERTY_ACCESSORIES. Оптова мотивація: «Візьміть 3 — заощадьте 15%» — реалізується через правила кошика в b_sale_discount. Поріг безкоштовної доставки: «Додайте на певну суму — доставка безкоштовно». Простий віджет, але збільшує середній чек на 10–20%.

Управління через адмінку

Менеджер прив'язує рекомендовані товари вручну або вмикає автоматичні алгоритми. Правила відображення: категорія, діапазон цін, наявність. A/B-тестування різних стратегій — без розробника.

Промокоди: правильна реалізація

Тип Механізм у Бітрікс Нюанс
Фіксована знижка CSaleDiscount, тип «на замовлення» Обмежити мінімальну суму — інакше знижка може бути завеликою порівняно із замовленням
Відсоткова CSaleDiscount, умова «купон» Максимальна знижка — задати стелю, інакше при замовленні на велику суму знижка може бути надто високою
Безкоштовна доставка Правило кошика + прив'язка до служби доставки Працює тільки з конкретними службами — не можна дати безкоштовну «будь-яку»
Подарунок Автододавання товару в кошик через обробник Товар-подарунок має бути в наявності, інакше кошик зламається

UX промокоду:

  • Поле видно, але не кричить — не відволікає тих, у кого коду немає.
  • Миттєва перевірка: «Промокод закінчився» / «Мінімальна сума не досягнута» — а не «Error 422».
  • Знижка видна в підсумковому розрахунку окремим рядком.
  • Можна прибрати промокод і застосувати інший.

UX-оптимізація: дрібниці, які вирішують

Десктоп:

  • Прогрес-бар — користувач бачить, де він.
  • Розумні дефолти — найпопулярніший спосіб доставки вже вибраний (визначаємо за статистикою b_sale_order).
  • Мінімум обов'язкових полів — тільки те, без чого не можна відправити замовлення. По батькові? Необов'язково. Коментар? Необов'язково.
  • Перерахунок без лоадерів на 5 секунд — debounce 300ms на AJAX-запитах.

Мобільні:

  • Великі кнопки — палець не промахується. min-height: 48px за гайдами Google.
  • Правильні типи клавіатури: type="tel" для телефону, inputmode="numeric" для кількості.
  • Кнопка «Оформити» зафіксована внизу — position: sticky.
  • Згорнуті секції — екранний простір на 375px дорогий.

Обробка помилок:

  • «Перевірте номер картки» замість «Payment processing error».
  • Автопрокрутка до першої помилки — scrollIntoView({ behavior: 'smooth' }).
  • «Товар закінчився» — обробляємо без втрати заповнених даних. Пропонуємо аналог або прибираємо з перерахунком.

Інтеграції

  • DaData — адреса, ПІБ, ІПН. Підказки під час введення, валідація ФІАС.
  • Google Maps — вибір пунктів видачі на карті, геолокація для визначення міста.
  • НПП, Boxberry, Укрпошта — API-розрахунок вартості та термінів у реальному часі.
  • LiqPay, CloudPayments, ПриватБанк — прийом платежів, рекурентні списання, холдування.
  • CRM — замовлення автоматично йде в Бітрікс24, створюється угода з прив'язкою до контакту.
  • Склад — перевірка залишків через CCatalogStoreProduct::GetList() у реальному часі.
Приклад AJAX-запиту для розрахунку доставки
// Псевдокод для паралельних запитів
$promises = [];
foreach ($tariffs as $tariff) {
    $promises[] = async(function() use ($tariff, $basket) {
        return $tariff->calculate($basket);
    });
}
$results = awaitAll($promises, 3000);

Що входить у роботу

  • Аналіз поточного чекауту та виявлення вузьких місць (аудит конверсії, логів, помилок).
  • Проєктування UX: прототипування однокрокової форми, узгодження із замовником.
  • Розробка компонента чекауту на основі Bitrix\Sale\Order + REST, з заміною sale.order.ajax.
  • Інтеграція з платіжними (LiqPay, CloudPayments, ПриватБанк) та логістичними API (НПП, Boxberry, Укрпошта).
  • Налаштування промокодів, крос-селу, покинутих кошиків.
  • Тестування на реальних сценаріях: десктоп, мобільні, планшети.
  • Передача документації (опис API, інструкції для менеджерів, доступи).
  • Навчання співробітників роботі з новим кошиком.
  • Пост-релізна підтримка — 2 тижні моніторингу та правок.

Строки

Задача Строк
Оптимізація поточного чекауту 1–2 тижні
Однокроковий чекаут з нуля 3–5 тижнів
Система промокодів 1–2 тижні
Крос-сел у кошику 1 тиждень
Механізм покинутих кошиків 2–3 тижні
Комплексна переробка 6–10 тижнів

Зв'яжіться з нами для обговорення вашого проєкту та отримайте консультацію з конкретних завдань. Замовте аудит кошика вже сьогодні — побачите, скільки конверсії втрачається на кожному кроці. Збільшення конверсії чекауту на 1–2% при стабільному трафіку — це зростання виручки без зростання рекламного бюджету. Найшвидший ROI в e-commerce.