Редактирование корзины прямо на странице оформления

Покупатель дошёл до последнего шага, заполнил адрес и вдруг понял: нужно две штуки, а не одна, и вон ту позицию лучше убрать. В магазинах, где корзину нельзя тронуть на странице оформления, начинается пляска: вернуться назад, поправить, снова пройти форму, заново выбрать доставку. Часть людей на этом просто уходит. На финальном экране, где до оплаты остаётся один клик, каждый лишний переход стоит дорого.

Эта статья — о том, как дать покупателю менять состав заказа прямо на странице оформления в 1С-Битрикс: увеличивать и уменьшать количество, удалять позиции, видеть мгновенный пересчёт цен, скидок и итога — без ухода со страницы и без потери заполненных полей. Разберём механику на объекте sale.order, AJAX-обновление и подводные камни с остатками. Если оформление уже подтормаживает, начать стоит с аудита и оптимизации 1С — часто корень в медленном обмене, а не во фронтенде.

Зачем править корзину на шаге оформления

Классический сценарий магазина разводит корзину и оформление на два экрана: сначала правишь состав, потом переходишь к контактам и доставке. Логика понятная, но она предполагает, что на финальном шаге пользователь уже ничего не хочет менять. На практике это не так: именно на оформлении человек внимательно смотрит на итоговую сумму, вспоминает про количество, замечает лишнюю позицию.

Если исправить это можно только возвратом в корзину, вы платите отказами. Каждый переход «назад» — это перезагрузка, риск потерять контекст и лишний повод передумать. Возможность подправить количество и удалить позицию не сходя с места превращает раздражающий тупик в спокойное действие: увидел, поправил, оплатил.

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

Что именно должен уметь пользователь

Прежде чем лезть в код, зафиксируйте набор действий, доступных прямо в блоке состава заказа:

• Менять количество. Кнопки «плюс/минус» и поле ввода с мгновенным пересчётом суммы позиции и итога.
• Удалять позицию. Одним действием, с возможностью отмены или хотя бы без случайных нажатий.
• Видеть актуальную цену. Цена позиции и итог обновляются после каждого изменения, включая скидки.
• Понимать ограничения. Если товара меньше, чем хочет покупатель, это видно сразу, а не после нажатия «Оформить».

Чего делать не стоит — превращать шаг оформления в полноценную корзину со всеми промо-блоками и рекомендациями. Задача финального экрана — довести до оплаты, а не удерживать. Редактирование должно быть лаконичным.

Как устроено оформление в 1С-Битрикс

В редакциях с модулем «Интернет-магазин» за оформление отвечает компонент sale.order.ajax (или его аналоги в готовых решениях). Он выводит форму заказа, состав корзины, выбор доставки и оплаты и уже умеет работать по AJAX — то есть пересчитывать заказ без полной перезагрузки. Это ключевой факт: чаще всего задачу решают не написанием оформления с нуля, а доработкой шаблона этого компонента.

Под капотом лежит объектная модель продаж на D7: Bitrix\Sale\Order как заказ, Basket как коллекция товаров, BasketItem как отдельная позиция. Именно через эти объекты идут добавление, изменение количества, удаление и пересчёт. Понимание, что работа с заказом — это работа с ORM-объектами, а не с прямыми SQL-запросами, экономит массу времени; базовые принципы мы разбирали в статье про D7 ORM в Битрикс.

Пересчёт заказа через sale.order

Главное правило: суммы, скидки и доставку не считает фронтенд. Считает сервер, а фронт лишь отображает результат. Когда пользователь меняет количество, происходит следующее:

1. Находим позицию. В коллекции корзины заказа берём нужный BasketItem по его идентификатору.
2. Меняем количество. Устанавливаем новое значение либо удаляем позицию из коллекции.
3. Запускаем пересчёт. Заказ пересчитывает суммы позиций, применяет правила работы с корзиной (скидки) и обновляет расчёт доставки.
4. Сохраняем и отдаём. Сохраняем заказ и возвращаем на фронт новые суммы, скидки и итог.

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

AJAX без перезагрузки страницы

Смысл всей затеи — обновлять корзину без ухода со страницы и без потери заполненных полей. Значит, изменение количества уходит на сервер асинхронным запросом, а в ответ приходит пересчитанный заказ, которым обновляют только нужные части страницы: строку позиции, блок итогов и, если поменялась, стоимость доставки.

Ключевой нюанс — не перерисовывать всю форму. Поля ФИО, адреса, комментария и выбранный способ доставки должны остаться нетронутыми. Поэтому обновляют точечно: заменяют DOM только там, где данные изменились. Если проект использует REST-эндпоинты для взаимодействия фронта с бэком, тем более важно закрыть их авторизацией и валидацией — об этом мы писали в материале про безопасность REST и вебхуков в Битрикс.

Остатки и наличие в момент правки

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

• Ограничение сверху. Если запрошено больше остатка, количество обрезается до доступного и показывается сообщение.
• Учёт резервов. Товар, зарезервированный под другие заказы, не должен «продаваться» повторно.
• Актуальность данных. Остатки приходят обменом с 1С; если обмен редкий, между показом и оформлением цифра успевает устареть.

Корректность остатков в конечном счёте упирается в учётную систему и её синхронизацию с сайтом. Настроить своевременный и точный обмен помогает автоматизация продаж и склада на 1С: точные остатки на витрине — это следствие порядка в учёте, а не только фронтендной проверки.

Скидки, промокоды и кратность

Изменение количества почти всегда затрагивает цену, и не только линейно. В 1С-Битрикс на состав корзины навешаны правила работы с корзиной: скидки от суммы, от количества, подарки при достижении порога, действие промокода. Всё это пересчитывается вместе с заказом — но только если вы гоняете изменение через штатный механизм.

Отдельная тема — кратность. Если товар продаётся упаковками или коробами, количество должно подгоняться под шаг заказа, а не принимать любое число. Это особенно характерно для опта: покупатель не может заказать 7 штук, если фасовка по 5.

UX: сообщения, состояния, мобильные

Техника — половина дела; вторая половина в том, как редактирование ощущается. Несколько принципов:

• Мгновенная обратная связь. После клика показывайте состояние загрузки на конкретной позиции, а не замораживайте всю страницу.
• Понятные сообщения. «Осталось 3 шт.», «Позиция удалена», «Товар продаётся по 5 шт.» — коротко и по делу.
• Защита от случайного удаления. Кнопку удаления не ставьте вплотную к «плюс/минус», особенно на мобильных.
• Стабильная вёрстка. Итог не должен «прыгать» при пересчёте — резервируйте место под суммы.

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

Реализация пошагово

Общий маршрут внедрения выглядит так. Названия пунктов зависят от редакции и решения, но логика единая:

1. Отталкивайтесь от штатного компонента. Проверьте, что оформление уже на sale.order.ajax и работает по AJAX — это фундамент.
2. Выведите управление в состав заказа. Добавьте в шаблон кнопки количества и удаления для каждой позиции.
3. Опишите обработчик изменения. На сервере: найти позицию, изменить количество или удалить, пересчитать заказ, вернуть суммы.
4. Точечно обновляйте DOM. Меняйте строку позиции, итоги и доставку, не трогая поля формы.
5. Проверяйте остаток и кратность. На сервере ограничивайте количество доступным и шагом заказа.
6. Пересчитывайте скидки. На том же ответе, что и суммы, чтобы экран и заказ совпадали.
7. Прогоните боевые сценарии. Товар кончился, промокод, пороги скидок, кратность, мобильный экран.

Если фронтенд оформления собирается сложным SPA-подходом с частыми деплоями, стоит заранее выстроить процесс выкладки — про это есть отдельный разбор про CI/CD и деплой в Битрикс.

Производительность и кэш

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

• Компактный ответ. Возвращайте только изменившиеся данные (суммы, скидки, доставка), а не всю страницу.
• Не тяните лишнее. При пересчёте не грузите рекомендации, баннеры и тяжёлые блоки — они не меняются.
• Кэшируйте статику. Шапка, подвал и неизменные части оформления не должны рендериться заново.
• Следите за обменом остатков. Частый узел торможения — не сам пересчёт, а запросы наличия к базе или к 1С.

На высоконагруженных проектах разница между «мгновенным» и «залипающим» оформлением обычно определяется инфраструктурой. Как выжать максимум из окружения на BitrixVM, мы разбирали в статье про хостинг и инфраструктуру BitrixVM.

Частые ошибки

• Считать сумму на фронте. Рано или поздно она разойдётся со скидочными правилами — и заказ уйдёт по неверной цене.
• Перерисовывать всю форму. Пользователь теряет заполненные поля адреса и доставки и вводит их заново.
• Не проверять остаток при правке. Заказ оформляется на количество, которого нет на складе.
• Игнорировать кратность. Для опта возможность заказать некратное число ломает отгрузку.
• Молчать об изменении итога. Пользователь не понимает, почему цена выросла после уменьшения количества (выпал из скидки).
• Тяжёлый пересчёт. Каждое нажатие «плюс» подвешивает страницу, потому что грузится всё подряд.
• Кнопка удаления вплотную к количеству. Случайные удаления на мобильных бьют по конверсии.

Чек-лист внедрения

1. Управление в составе заказа. Количество и удаление доступны прямо на шаге оформления.
2. Пересчёт через объект заказа. Суммы, скидки и доставка считает сервер, а не фронт.
3. Точечное обновление DOM. Обновляются только позиция и итоги, поля формы не сбрасываются.
4. Проверка остатка. Количество ограничивается доступным на сервере, с сообщением пользователю.
5. Кратность соблюдена. Шаг заказа для упаковок учитывается.
6. Скидки пересчитаны. Экран и реальный заказ всегда показывают одинаковый итог.
7. Мобильный протестирован. Зоны нажатия крупные, случайные удаления исключены.
8. Скорость проверена. Ответ пересчёта компактный, статика закэширована.

Вывод

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

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