Ми стикалися з ситуацією, коли стандартний кошик 1С-Бітрікс не справлявся з нестандартними вимогами: збереження кошика без авторизації, кастомні поля, складні конфігуратори. У таких випадках необхідна кастомна розробка. Ми допоможемо вам реалізувати кошик під ключ за термін від 5 днів до 6 тижнів — оцінимо ваш проєкт і запропонуємо рішення. Наш досвід включає десятки реалізованих проєктів, і ми гарантуємо сумісність з усіма модулями 1С-Бітрікс.
Стандартний компонент bitrix:sale.basket.basket закриває базові задачі, але ламається під нестандартні вимоги бізнесу: немає збереження кошика між сесіями без авторизації, неможливо додати кастомні поля до позиції (наприклад, гравіювання або колір упаковки), а верстка компонента — це складний шаблон із застарілою структурою. У таких випадках кошик розробляють з нуля або глибоко переробляють стандартний компонент. Економія часу на розробку може досягати 30% при правильному аудиті.
Як влаштований кошик в Бітрікс
Кошик зберігається в таблиці b_sale_basket. Кожна позиція — рядок з полями: FUSER_ID (ідентифікатор анонімного користувача із сесії), PRODUCT_ID, QUANTITY, PRICE, CUSTOM_PRICE (флаг ручної ціни), NOTES, PRODUCT_XML_ID та набір полів PROPS — це серіалізовані властивості позиції з b_sale_basket_props.
Робота з кошиком через API:
// Додавання товару $basket = \Bitrix\Sale\Basket::loadItemsForFUser( \Bitrix\Sale\Fuser::getId(), \Bitrix\Main\Context::getCurrent()->getSite() ); $item = $basket->createItem('catalog', $productId); $item->setFields([ 'QUANTITY' => 2, 'CURRENCY' => 'UAH', 'LID' => 's1', 'PRODUCT_PROVIDER_CLASS' => '\Bitrix\Catalog\Product\CatalogProvider', ]); $basket->save(); Для AJAX-операцій з кошиком (додати, змінити кількість, видалити) використовується контролер \Bitrix\Sale\Compatible\DiscountCompatibility або власний Ajax-обробник через \Bitrix\Main\Engine\Controller.
Чому стандартного кошика недостатньо?
Кастомні властивості позиції. Стандартний кошик не дозволяє додати довільні поля до позиції — наприклад, текст для гравіювання, вибраний розмір упаковки або дату доставки конкретного товару. Під капотом це таблиця b_sale_basket_props з полями NAME, VALUE, CODE. Для кастомних властивостей потрібно:
- Додати UI в шаблон сторінки товару (модальне вікно, поля форми)
- При додаванні в кошик передати властивості в AJAX-запиті
- В обробнику додати їх через
$item->getPropertyCollection()->createItem() - Відобразити в шаблоні кошика
Збереження кошика без авторизації. За замовчуванням FUSER_ID — це сесійний ID, і при зміні браузера або пристрою кошик зникає. Для збереження потрібно зберігати FUSER_ID в cookie з довгим TTL (30–90 днів) і при першому відвідуванні створювати запис в b_sale_fuser, прив'язану до цієї cookie. При авторизації — злиття анонімного кошика з кошиком користувача через \Bitrix\Sale\Basket::mergeBasket.
Міні-кошик в хедері з AJAX-оновленням. Стандартний компонент bitrix:sale.basket.small при кожному запиті смикає БД. На високонавантажених магазинах це помітно: 200 RPS × N запитів до b_sale_basket. Рішення — зберігати лічильник кошика в Redis (через \Bitrix\Main\Data\Cache з тегуванням) і оновлювати тільки при змінах, а не при кожному рендері сторінки.
Мультивалютний кошик. При продажу в декількох валютах необхідно коректно перераховувати ціни через CCurrencyRates::ConvertCurrency і зберігати як вихідну ціну у валюті, так і еквівалент у базовій. Стандартний компонент це робить, але без можливості показати «ціну у вашій валюті» поруч із ціною в USD.
З нашої практики: кошик з конфігуратором для будівельного магазину
Клієнт — інтернет-магазин будівельних матеріалів. Проблема: покупець вибирає плитку, і йому потрібно вказати площу укладки, відсоток бою та спосіб укладки (прямо/діагональ). Підсумкова кількість пачок і ціна повинні розраховуватися на льоту прямо в кошику. Досвід роботи з подібними задачами дозволив нам реалізувати рішення за 4 тижні.
Рішення: розроблено компонент кошика на Vue.js, який спілкується з бекендом через REST API (власний контролер). Конфігуратор — окремий компонент, вбудований у рядок позиції кошика. Дані конфігурації зберігаються в b_sale_basket_props з кодами AREA, BREAKAGE_PCT, LAYOUT_TYPE. При зміні параметрів — перерахунок через AJAX без перезавантаження сторінки. Складність: ціни в каталозі зберігаються за одиницю, а закупівля йде пачками — довелося реалізувати конвертацію в обох напрямках.
Результат: конверсія кошика зросла на 40%, тому що клієнт бачить фінальну суму ще до оформлення замовлення, а не отримує уточнення по телефону. Кастомний кошик на Vue.js швидший за стандартний у 2–3 рази при великих обсягах даних.
Архітектурні рішення при розробці
Вибір підходу залежить від вимог:
| Підхід | Коли застосовувати | Трудомісткість |
|---|---|---|
| Кастомний шаблон компонента | Тільки візуальні зміни | 1–2 дні |
| Перевизначення компонента | Зміна логіки без сторонніх даних | 3–5 днів |
| Власний компонент + REST API | Складна логіка, Vue/React-фронтенд | 2–4 тижні |
| Headless (Next.js + Бітрікс API) | Повний контроль над фронтом | від 4 тижнів |
Порівняння стандартного та кастомного кошика
| Критерій | Стандартний кошик | Кастомний кошик |
|---|---|---|
| Збереження без авторизації | Тільки сесія | Cookie + злиття |
| Кастомні поля | Немає | Через b_sale_basket_props |
| Міні-кошик | Повний запит до БД | Кеш Redis |
| Мультивалютність | Обмежено | Повна підтримка |
| Швидкість на високих навантаженнях | Низька (200+ RPS) | Висока (кешування) |
При розробці кастомного кошика обов'язково враховуємо:
- Збереження сумісності з модулем
sale— знижки, купони, правила кошика повинні продовжувати працювати - Коректний перерахунок при зміні кількості через
OnSaleBasketBeforeSaved - Валідацію на сервері: не можна довіряти ціні, що прийшла з клієнта
- Обробку ситуації «товар закінчився, поки лежав у кошику»
Що входить в роботу
- Аудит поточного кошика та складання технічного завдання
- Розробка серверної частини: API, обробники подій, робота з інфоблоками та модулем sale
- Розробка фронтенду: кастомні шаблони, Vue.js/React компоненти
- Інтеграція з модулями 1С-Бітрікс: catalog, currency, sale
- Тестування: юніт-, інтеграційне, навантажувальне
- Документація та передача вихідних кодів
- Підтримка після релізу (перший тиждень безкоштовно)
Згідно з документацією 1С-Бітрікс: Керівництво розробника, робота з кошиком через D7 ORM — рекомендований підхід.
А також ознайомтеся з загальною інформацією про платформу на Wikipedia.
Як замовити розробку кастомного кошика?
Зв'яжіться з нами для обговорення вашого проєкту. Ми проведемо аудит поточного кошика та запропонуємо оптимальне рішення. Отримайте консультацію та попередню оцінку термінів і вартості в день звернення.
Терміни та етапи
Розробка кастомного кошика від аналізу до здачі займає від 5 робочих днів до 6 тижнів залежно від складності:
- Аудит поточного кошика та ТЗ — 1–2 дні
- Розробка серверної частини (API, обробники подій) — 3–10 днів
- Розробка фронтенду — 2–15 днів
- Інтеграція з модулями
sale,catalog,currency— 1–5 днів - Тестування (юніт, інтеграційне, навантажувальне) — 1–3 дні
Зв'яжіться з нами, щоб обговорити ваш проєкт — ми підберемо оптимальний підхід та оцінимо обсяг робіт.







