Кастомний кошик 1С-Бітрікс: де ламається стандартний сценарій
Стандартний кошик 1С-Бітрікс тримається на зв'язці компонента оформлення замовлення, правил роботи з кошиком і обробників подій. Поки сценарій типовий — товар, знижка, доставка — він працює передбачувано.
Щойно з'являється нестандартна логіка, штатний механізм починає конфліктувати сам із собою, і вузьке місце майже завжди виявляється в одному з трьох місць.
Перше — правила знижок і бонусів. Кілька правил, накладених на одну позицію, перераховуються в порядку пріоритету, і при перетині умов підсумкова ціна може обнулитися або піти в мінус.
Друге — перерахунок кошика при зміні кількості або зміні складу: позиції, прив'язані до залишків, мовчки випадають із замовлення, а покупець бачить уже інший склад.
Третє — оформлення замовлення під навантаженням: синхронні запити до каталогу і складу на кожному кроці тримають сесію, і при піковій відвідуваності крок підтвердження зависає.
Ціна цих збоїв — покинуті кошики на останньому кроці, розбіжності між замовленням і фактичною наявністю, ручні правки менеджерів.
Кастомний кошик 1С-Бітрікс потрібен не заради «краси» інтерфейсу, а щоб розвести ці сценарії: винести розрахунок знижок в окремий шар із прозорими правилами, зафіксувати склад замовлення на момент підтвердження і розвантажити оформлення замовлення від важких запитів. Нижче розбираємо, як це закривається.
Що дає перероблений кошик: вимірюваний ефект
Перероблений кошик — це не «косметика» інтерфейсу, а перебудова логіки оформлення замовлення. Ми розбираємо шлях покупця крок за кроком, знаходимо, де він втрачає час і йде, та переписуємо ці ділянки.
У результаті конверсія оформлення зростає завдяки тому, що людина проходить шлях без зайвих кліків і очікувань, а не завдяки знижкам і тиску.
Швидкість відгуку кошика безпосередньо впливає на частку покинутих кошиків. Коли перерахунок вартості, знижок і доставки відбувається миттєво, покупець не встигає засумніватися й закрити вкладку.
Ми виносимо важкі операції із синхронного запиту, кешуємо проміжні розрахунки й віддаємо готовий результат — на практиці це скорочує частку покинутих кошиків у рази, а не на відсотки.
Окрема історія — пікове навантаження. Розпродажі та сезонні сплески ламають кошик не тому, що бракує заліза, а тому, що логіка перерахунку блокує сесії.
Ми проєктуємо оформлення так, щоб одночасні замовлення не конкурували за одні й ті самі дані: черги, розділення читання й запису, відмовостійкі сценарії за недоступності зовнішніх сервісів. Кошик продовжує приймати замовлення, навіть коли один із суміжних сервісів відповідає із затримкою.
Ефект видно в цифрах: час оформлення скорочується, частка покинутих кошиків падає, а за пікового навантаження система тримає потік без помилок і повторних спроб. Саме ці метрики ми фіксуємо до та після переробки, щоб результат був перевірюваним, а не декларативним.
Підходи до реалізації: порівняння варіантів
Вибір підходу визначає, що буде з кошиком при наступному оновленні платформи і як швидко ви зможете змінювати правила розрахунку. Три робочі варіанти різняться точкою втручання: правки у штатному компоненті, власний компонент з нуля або винесення логіки розрахунку за межі сайту.
| Варіант | Коли підходить | Обмеження підходу |
|---|---|---|
| Допрацювання штатного компонента | Типовий сценарій: стандартні знижки, один склад, проста доставка. Потрібно швидко і з мінімальним обсягом коду | Правки в шаблоні та обробниках затираються при оновленні ядра — після кожного апдейту потрібна ревізія. Логіка розрахунку залишається всередині сторінки, її важко перевикористати |
| Власний компонент | Нестандартні правила: набори товарів, кілька складів, свої умови доставки, інтеграція із зовнішніми системами | Потребує своєї моделі даних і покриття перевірками. Довше на старті, зате оновлення платформи не ламають логіку |
| Зовнішній розрахунок в окремому сервісі | Розрахунок спільний для сайту, мобільного застосунку і відділу продажів; правила змінюються часто | Потрібні синхронізація каталогу і цін, обробка недоступності сервісу та зрозумілий відкат до останнього коректного стану кошика |
Штатний компонент дає результат швидко, але накопичує зв'язаність: чим більше умов ви в нього додаєте, тим дорожча кожна наступна зміна.
Власний компонент знімає це обмеження, але переносить відповідальність за сумісність на вашу команду — ми фіксуємо контракти з ядром і закриваємо їх перевірками.
Зовнішній розрахунок виправданий, коли одна й та сама логіка потрібна кільком каналам продажів. Тоді кошик на сайті стає тонким клієнтом, а правила живуть в одному місці — правка застосовується одразу всюди, без релізу вітрини.
На практиці частіше обирають другий варіант: він зберігає контроль над розрахунком і не залежить від оновлень ядра. Обговоримо ваші сценарії — повернемося з оцінкою та планом за обраним підходом.
Етапи робіт: від аудиту поточного кошика до передачі
Роботу починаємо з аудиту поточного кошика, а не з правок шаблону. Дивимося, де обчислюється підсумок: у компоненті, в обробнику оформлення замовлення чи в модулі, які події підключені до перерахунку, як зберігаються знижки та правила доставки.
На виході — карта вузьких місць: де логіка дублюється, де ціна перераховується двічі, де при зміні кількості позиції «пливе» підсумок.
Далі проєктуємо схему розрахунків окремо від верстки. Правила знижок, націнок, округлення та доставки описуємо як самостійний шар — тоді кошик рахує однаково на сторінці, в оформленні та в листі клієнту.
Схему узгоджуємо до коду: розбіжність у правилах на цьому кроці коштує дешевше, ніж переробка після запуску.
- Аудит кошика: розбір поточної логіки, подій, точок перерахунку та накопичених правок.
- Схема розрахунків: правила знижок, округлення, доставки та податків в одному місці, з явним порядком застосування.
- Реалізація: винесення логіки в окремий шар, підключення до компонента та оформлення замовлення.
- Перевірка сценаріїв: зміна кількості, видалення позиції, промокод, поріг доставки, перерахунок при зміні регіону.
- Навантажувальна перевірка: поведінка кошика при великій кількості позицій та одночасних сесіях.
- Передача рішення: документація щодо схеми розрахунків, інструкція для контент-менеджера, доступи та порядок відкату.
Перевірку сценаріїв ведемо за списком, а не «на око»: кожен випадок проганяємо на тестових даних і фіксуємо очікуваний підсумок. Окремо перевіряємо, що після відкату на попередню версію кошик рахує за старою схемою — це страховка на час запуску.
Передача рішення — це не архів із файлами, а робоча схема: де лежать правила, як додати нову знижку, що робити при розбіжності підсумків. Опишіть вашу задачу — повернемося з оцінкою та планом за цими етапами.
Що замовник отримує на руки після впровадження
Впровадження вважається завершеним не тоді, коли кошик «працює в нас», а тоді, коли ваша команда може його супроводжувати без нас.
Тому передаємо не лише код, а й увесь контур: конфігурації, схеми розрахунків, регламенти та документацію, за якою новий розробник вводиться в проєкт за дні, а не тижні.
- Конфігурації та налаштування — правила розрахунку знижок, порогів доставки, податкових режимів і округлень винесені в керовані параметри, а не зашиті в код. Маркетинг змінює умови акції сам, без правки шаблону кошика.
- Схеми розрахунків — діаграми проходження замовлення: від додавання товару до передачі в 1С, з точками валідації залишків, цін і мінімальної суми. Видно, де спрацьовує яке правило і що станеться при відмові.
- Регламенти обміну з 1С — періодичність синхронізації каталогу, цін і замовлень, поведінка при розбіжності даних, порядок ручного розбору конфліктів. Окремо — що робити при недоступності зовнішньої системи.
- Документація по коду — опис модулів кошика, точок розширення та залежностей між компонентами. З позначками, які місця правляться під типові задачі, а які потребують узгодження.
- Інструкції для команди — покрокові сценарії для контент-менеджера та адміністратора: як змінити умову знижки, додати спосіб доставки, перевірити зависле замовлення.
- План відкату — які налаштування та дані повертаються до попереднього стану при збої, у якому порядку і за який час. Перевіряється на тестовому контурі до передачі.
- Доступи та середовища — розділення тестового та робочого контурів, права ролей, порядок викладки змін без зупинки приймання замовлень.
Кожен артефакт проходить приймання на вашій стороні: ми показуємо, як ним користуватися, і фіксуємо, що команда відтворює сценарій самостійно. Якщо за підсумком щось залишається незрозумілим — це наша недоробка в документації, а не питання до вашої команди.
Кейс: як перероблений кошик усунув втрати замовлень
Проєкт — інтернет-магазин електроніки на 1С-Бітрікс: каталог із десятками тисяч позицій, оформлення замовлення через штатний компонент кошика. Проблема проявилася не в трафіку, а в конверсії останнього кроку: покупці доходили до оформлення й ішли.
Штатний механізм перераховував кошик при кожній зміні кількості, синхронно звертався по залишки й ціни в 1С, а при паралельних замовленнях однієї позиції не резервував товар до фінального підтвердження. Підсумок — «завислі» кошики, помилки при списанні та замовлення, які менеджери розбирали вручну.
Що було до переробки
Частка успішних оформлень трималася на рівні 61%: частина покупців отримувала помилку на кроці підтвердження й ішла.
Середній відгук кошика при перерахунку сягав 4-6 секунд — при повільній відповіді 1С інтерфейс підвисав, і люди повторно натискали кнопку, створюючи дублі замовлень.
Підтримка приймала близько 180 звернень на місяць, з них більше половини — «замовлення не оформилося», «товар зник із кошика», «надійшло два однакових замовлення».
Що змінили
Переписали кошик як окремий шар поверх штатного сховища: стан замовлення живе на клієнті, а обмін із 1С відбувається асинхронно, з кешем цін і залишків.
Резерв товару тепер ставиться на момент додавання в кошик із таймаутом, а не на фінальному кроці, — гонки за останню одиницю зникли. Додали ідемпотентність оформлення: повторний запит із тим самим ідентифікатором не створює друге замовлення, а повертає результат першого.
Що стало після
Частка успішних оформлень зросла з 61% до 89%. Відгук кошика при перерахунку скоротився до 0,4-0,8 секунди — інтерфейс реагує миттєво, повторні натискання зникли.
Звернення до підтримки на тему оформлення впали з 180 до 40 на місяць, а частка замовлень, що потребують ручного розбору, знизилася з 12% до 2%. Окремо зафіксували: розбіжностей між кошиком і фактичним списанням у 1С після впровадження резерву не залишилося.
Чим відрізняється доопрацювання штатного кошика від власного компонента?
Штатний кошик — це готовий компонент із фіксованим набором точок розширення: шаблон, обробники подій, налаштування оформлення замовлення.
Поки завдання вкладається в цей набір — доопрацювання штатного кошика дешевше й швидше: не потрібно проєктувати модель даних, логіку перерахунку та сценарії оформлення з нуля.
Правки локалізовані, оновлення платформи переносяться передбачувано, а розробник, який повернувся до проєкту через рік, бачить стандартну структуру, а не самописну.
Власний компонент потрібен там, де логіка виходить за межі типового сценарію: нестандартні правила розрахунку знижок, комплекти й набори, кошик із кількома постачальниками, обмін з обліковою системою в реальному часі.
Тут гнучкість вища — ви керуєте структурою даних і порядком операцій, а не підлаштовуєтеся під чужу архітектуру. Але ця свобода оплачується двічі: на етапі розробки та протягом усього терміну підтримки.
Ключова різниця проявляється не в момент запуску, а під час подальшого розвитку. Доопрацювання штатного кошика накопичує зміни шарами: кожна нова вимога чіпляється за попередню, і через кілька ітерацій розібратися в них може лише автор правок.
Власний компонент вимагає дисципліни — документація, покриття перевірками, ізоляція бізнес-логіки, — але натомість дає передбачувану підтримку: нова функція додається у відоме місце, а не шукається по всій кодовій базі.
Практичний критерій вибору простий. Якщо нестандартних вимог менше чверті від загального обсягу логіки кошика — доопрацювання штатного обійдеться дешевше і на старті, і в підтримці.
Якщо більше — власний компонент окупається вже на другій-третій ітерації доопрацювань, бо кожна наступна правка коштує менше, а ризик зламати суміжний сценарій — нижчий.
Ми зазвичай починаємо з аудиту поточного кошика: дивимося, які точки розширення вже задіяні, скільки правок накопичилося і які вимоги стоять у черзі.
За цією картиною видно, де закінчується сенс доопрацьовувати штатне і починається сенс писати своє — і якою є вартість підтримки в кожному з варіантів.
Часті технічні сумніви перед стартом
Перед стартом робіт технічні керівники ставлять одні й ті самі запитання: чи не зламає доопрацювання штатний механізм, що буде при оновленні платформи та чи збережуться чинні правила знижок. Нижче — прямі відповіді без маркетингу, щоб ви могли оцінити ризики до початку проєкту.
Доопрацювання кошика конфліктує зі штатним механізмом оформлення замовлення?
Ні, якщо працювати через події та наслідування, а не правкою ядра. Логіка підключається як окремий модуль: перевизначаються шаблони компонента, додаються власні обробники на події розрахунку вартості та оформлення.
Штатний сценарій залишається робочим — при вимкненні модуля кошик повертається до типової поведінки. Сумісність з оновленнями платформи забезпечується саме цим: правки не зачіпають файли ядра, тому оновлення не затирає доопрацювання.
Що станеться при оновленні платформи?
Доопрацювання живе у власному модулі та кастомному шаблоні, тому оновлення ядра його не зачіпає.
Перед виведенням оновлення в робоче середовище ми проганяємо сценарії оформлення замовлення на копії: розрахунок знижок, застосування купонів, перерахунок доставки, оформлення з кількома складами.
Якщо в новій гілці змінюється сигнатура події або поведінка компонента — адаптуємо обробник. Так оновлення перестає бути ризиком простою.
Чи збережуться поточні правила знижок і накопичені дані?
Так. Правила знижок переносяться як є: знижки на кошик, накопичувальні, прив'язані до груп користувачів і сегментів, купони та умови за сумою замовлення.
Ми фіксуємо поточну логіку в специфікації, переносимо її в нову механіку та звіряємо результат на тестових замовленнях — підсумкова сума має збігатися до копійки.
Історія замовлень, прив'язка користувачів і кошики в базі не чіпаються: доопрацювання змінює розрахунок і відображення, а не структуру зберігання.
Чи можна відкотити зміни, якщо щось піде не так?
Так. Робота йде в окремій гілці з поетапним виведенням: спочатку тестове середовище, потім робоче з можливістю швидкого повернення до попереднього стану. Оскільки ядро не правиться, відкат — це вимкнення модуля та повернення шаблону, а не відновлення з резервної копії. Усі зміни версіонуються, тому можна повернутися до будь-якої точки.
Якщо залишилися сумніви щодо вашої конфігурації — опишіть задачу, і ми повернемося з оцінкою сумісності та планом робіт.
Обговоримо ваше завдання щодо кошика
Опишіть поточну ситуацію: на якому етапі ламається кошик, які сценарії покупки не відпрацьовують, що вже пробували змінювати. Цього достатньо, щоб наші інженери повернулися з оцінкою робіт і планом — без зобов'язань і без «спочатку підпишіть».
Щоб розмова була предметною, корисно заздалегідь зібрати кілька ввідних. Вони не потребують доступу до сервера і зазвичай уже є у вашої команди:
- який тип кошика зараз використовується і що саме в ньому не влаштовує — швидкість, логіка розрахунку, інтеграція з 1С;
- які сценарії покупки критичні: самовивіз, кілька складів, оптові ціни, подарункові набори, часткове відвантаження;
- як влаштований обмін з 1С — що і як часто синхронізується, де виникають розбіжності за залишками та цінами;
- які ролі користувачів працюють із замовленням і які права їм потрібні;
- чи є на сайті нестандартні правила: мінімальна сума, ліміти за регіонами, індивідуальні умови для юросіб;
- які метрики важливі: конверсія в замовлення, частка покинутих кошиків, час оформлення, кількість звернень до підтримки;
- що вже робилося раніше і чому результат не влаштував.
За цими ввідними ми оцінюємо обсяг: доопрацювання наявного кошика чи переписування логіки з нуля, які модулі зачіпаємо, чи потрібна міграція накопичених замовлень.
Далі готуємо план робіт за етапами — з пріоритетами, залежностями і точками, де можна перевірити результат до фінального запуску.
Оцінка і план надходять із розбивкою за етапами та зрозумілими критеріями готовності, щоб ви могли звірити їх зі своєю стороною. Якщо під час розбору з'ясується, що завдання вирішується налаштуванням без розробки, ми скажемо про це прямо.
Опишіть завдання у зручному форматі — повернемося з оцінкою та планом робіт.
