Порядок оплаты и доставки в корзине: как превратить макет в проверяемый сценарий заказа

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

Разделите порядок на экране и зависимость расчёта

Визуальное расположение определяет, что человек видит раньше. Логическая зависимость определяет, какие данные нужны для выбора следующего значения. Эти вещи связаны, но не совпадают автоматически. Можно показать оплату выше, сохранив явное ожидание выбора доставки, либо изменить сам процесс, если это согласовано.

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

Если утверждённый макет конфликтует с действующим правилом, зафиксируйте конкретный сценарий и выберите минимальное понятное решение. Например, оплата может показывать список с пояснением, что окончательная доступность проверится после доставки. Скрытая автоматическая смена выбора без сообщения не является хорошей адаптацией макета.

Состояния блоков нужно описать заранее

Для каждого блока определите пустое состояние, готовность, обработку и ошибку. Если доставка ещё не рассчитана, итог не должен выглядеть окончательным. Если оплата недоступна при выбранной службе, пользователь должен понимать причину и иметь путь выбора альтернативы.

Не используйте одну и ту же подпись для отсутствия вариантов и временного ожидания. «Загружаем способы» отличается от «Для этого адреса способ недоступен». Различение помогает человеку принять решение и даёт проверяющему наблюдаемые состояния, а не только исчезнувший список.

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

Сохранение выбранных значений

Покупатель может вернуться к доставке после выбора оплаты. Если новое значение совместимо, прежний платёжный способ следует сохранить по согласованному правилу. Если несовместимо, его сбрасывают или предлагают замену с понятным сообщением. Нельзя оставлять скрытый старый код под новой визуальной отметкой.

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

Если состояние хранится в общей модели формы, оба представления должны читать именно её. Дублирование значений в нескольких скрытых полях создаёт риск отправить старую копию. Источник истины должен быть один для каждого параметра, а отображение может существовать в нескольких местах.

Асинхронные ответы не должны возвращать старое состояние

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

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

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

Итоги заказа должны обновляться согласованно

Стоимость товаров, доставки и общая сумма относятся к одному состоянию корзины. Если один блок обновился, а итог остался прежним, человек не может понять цену оформления. Определите, когда итог считается готовым и как это видно во время пересчёта.

Не подставляйте 0 при ошибке тарифа, если это не реальное согласованное условие бесплатной доставки. Ошибка расчёта должна оставаться ошибкой, а не выглядеть как коммерческое предложение. То же относится к временно отсутствующей платёжной комиссии, если она существует в проекте.

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

Мобильный порядок и порядок фокуса

CSS может визуально переставить блоки, сохранив прежний порядок в документе. Для клавиатуры и вспомогательных технологий последовательность тогда будет отличаться от видимой. Проверьте, соответствует ли DOM смысловому порядку и не приходится ли человеку переходить фокусом через экран в неожиданной последовательности.

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

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

Проверьте сохранённый заказ

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

Документация 1С-Битрикс разделяет роли заказа, оплаты и отгрузки. При приёмке это означает необходимость проверить соответствующие сохранённые объекты, если они используются. Не смешивайте создание заказа с фактическим проведением платежа или передачей отправления перевозчику.

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

Матрица совместимости

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

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

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

Что считать завершённой вёрсткой корзины

Блоки расположены по согласованному дизайну, логические зависимости сохранены, ввод не теряется, устаревшие ответы не перезаписывают новый выбор, сервер принимает допустимый набор и заказ хранит ожидаемые значения. Эти условия превращают макет в работающий сценарий.

В документации оставьте краткую карту зависимостей и контрольные сочетания. Тогда следующая визуальная правка сможет пройти целевую проверку, а не начинать исследование корзины заново. Совпадение скриншота с макетом остаётся частью приёмки, но не заменяет её функциональную сторону.

Подробная последовательность приёмки перестановки

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

Вернитесь к прежней доставке. Решите заранее, восстанавливается ли прежний платёжный выбор или требуется новое подтверждение. Важно, чтобы видимая отметка и отправляемый код совпадали. Нельзя оставлять в скрытом поле прежний вариант под визуально выбранной новой строкой.

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

Сравнение настольного и мобильного порядка

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

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

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

Тест с запоздавшим тарифом

На стенде запустите расчёт для адреса А и задержите ответ. Затем выберите адрес Б и завершите его расчёт. После этого отпустите первый ответ. Итоговый экран должен оставаться связанным с последним актуальным адресом. Такой опыт выявляет риск, который почти не виден при быстрой сети.

Если старый ответ отклоняется, полезно видеть это в техническом журнале без контактных данных. Если он всё же принят, исправление должно касаться связи запроса и состояния. Добавление ещё одного общего таймера не делает порядок ответов надёжным.

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

Финальное сохранение и подтверждение

Оформите один учебный заказ после всех переключений и перечитайте его. Сравните службу, оплату, адрес и итог. Если пользователь видел одно, а сохранено другое, визуальная перестановка ещё не принята, даже при точном совпадении с макетом.

Сохраните короткую таблицу ожидаемых переходов для будущего регресса. Она позволяет быстро проверить следующую правку корзины и отличить существующее ограничение от нового дефекта. Доказательство относится к конкретным поддерживаемым сочетаниям, а не к любым возможным службам и платёжным системам.

Для иллюстрации используйте нейтральную учебную корзину без реальной оплаты. Пара состояний до и после смены доставки объясняет зависимость лучше, чем одиночный скриншот двух переставленных заголовков.

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

Связанные разборы

Для смежных решений пригодятся материалы: Мобильная версия интернет-магазина: проверка перед запуском. Общий путь оформления заказа полезен для проверки соседних шагов. После перестановки блоков повторно сверяйте доступную доставку, оплату и сохранённый заказ.

Вопросы по теме

Можно ли просто поменять CSS-порядок блоков?

Только если сохраняются смысловая последовательность, фокус и зависимости данных. Это нужно проверить, а не предположить.

Нужно ли сбрасывать оплату при любой смене доставки?

Не обязательно. Совместимый выбор можно сохранить; несовместимый обрабатывается по явному правилу с понятным сообщением.

Документация и источники

• 1С-Битрикс: службы доставки: Условия, местоположения и ограничения доставки связаны с параметрами заказа.
• 1С-Битрикс: объекты интернет-магазина: Заказ, оплата и отгрузка имеют отдельные роли; бонусный договор статьи не объявлен штатной функцией.
• MDN: проверка веб-форм: Клиентская проверка не заменяет серверную.