Покупатель выбирает синий размер M, а в корзине видит красный L. Сначала найдите первый шаг, где выбранный вариант расходится с данными: карточка → запрос добавления → сохранённая корзина → заказ. Сравнивайте идентификатор варианта и его свойства: одной правильной подписи или фотографии недостаточно, чтобы считать ошибку исправленной.
Кому это актуально
Разбор пригодится владельцу интернет-магазина, которому нужно поставить разработчику проверяемую задачу: неверный вариант добавляется всегда, после быстрого переключения свойств или только при повторной покупке. Результатом первичной проверки станет конкретная граница сбоя, а не предположение «сломалась корзина».
Торговое предложение — продаваемый вариант товара, например определённое сочетание цвета и размера. В 1С-Битрикс для таких вариантов предусмотрены торговые предложения, в WooCommerce — вариации. У других платформ модель может отличаться: где-то используются отдельные товары, где-то товар вместе с набором опций. Названия полей и способ сопоставления нужно уточнять для установленной системы и её доработок.
Как проследить выбранный вариант
Возьмите один контрольный товар с несколькими различимыми сочетаниями свойств. На согласованной тестовой копии пройдите путь по шагам и запишите ожидаемое и фактическое значение на каждой границе.
| Шаг | Что сопоставить |
|---|---|
| Карточка | Выбранные цвет и размер, соответствующий вариант в каталоге |
| Запрос добавления | Идентификатор варианта либо товар и опции, которые действительно отправил браузер |
| Ответ и сохранённая корзина | Вариант, свойства и количество после обработки запроса |
| Повторное открытие корзины | Сохранился ли выбор после перезагрузки страницы |
| Тестовый заказ | Какой вариант записан в составе заказа, а не только показан на экране |
Идентификатор товара, идентификатор варианта и идентификатор строки корзины — разные сущности. Они не обязаны совпадать между собой. Проверяют, на какой вариант ссылается строка, а при передаче в другую систему — корректность таблицы соответствий.
Артикул тоже не всегда достаточен для проверки. Например, WooCommerce может использовать артикул родительского товара, если у вариации собственный артикул не заполнен. Поэтому одинаковая надпись SKU ещё не доказывает, что выбрана одна и та же вариация.
Проверку сохранённого заказа проводите на тестовом контуре с отключённой отправкой в реальные оплаты, уведомления и складские системы. Не оформляйте настоящие покупки ради диагностики. Для первичного описания достаточно безопасно зафиксировать уже наблюдаемый симптом.
Четыре гипотезы и признаки для проверки
1. Переключатель изменил картинку, но отправил прежний вариант
Сравните медленное последовательное переключение цвета и размера с быстрым переключением. Если ошибка появляется только во втором случае, разработчику стоит проверить, не перезаписывает ли запоздавший ответ прежний выбор и успевает ли кнопка добавления получить актуальные данные.
Признак этой гипотезы: на экране выбран один вариант, но в запросе добавления уже указан другой. Это сужает проверку до состояния карточки и её обработчиков; ещё не доказывает неисправность конкретного скрипта. Отдельно повторите сценарий из списка товаров и из быстрого просмотра, если такие способы покупки предусмотрены.
2. Сочетание свойств связано с неверным предложением
В административном интерфейсе сравните полный набор свойств у двух вариантов, которые путаются. Проверьте, существуют ли нужные сочетания, нет ли ошибочной привязки к другому товару и не используется ли слишком широкое правило выбора.
В WooCommerce вариации со значением «любой» для свойства могут пересекаться с более точными вариациями; при совпадениях имеет значение порядок поиска. Это пример возможной неоднозначности данных, а не универсальное объяснение для всех магазинов.
Если неверные свойства уже видны в каталоге после обмена с учётной системой, начните с проверки данных. Для отдельного сценария обмена есть разбор цен и остатков из 1С в Битрикс. Изменение кнопки покупки не исправит ошибочное соответствие в источнике.
3. Сервер получил верный выбор, но сохранил другой
Если запрос содержит ожидаемый вариант, а сохранённая корзина — другой, проверяйте обработку добавления. Возможные причины: поиск по родительскому товару вместо варианта, потеря части опций, нестандартная подстановка при недоступности выбранного предложения.
Безопасный критерий поведения нужно согласовать заранее: недоступное сочетание не должно незаметно заменяться другим. Покупателю требуется понятное сообщение и возможность выбрать доступный вариант. Сам сервер должен проверять допустимость сочетания; правильный вид переключателей не заменяет эту проверку.
4. Разные варианты объединяются или неверно отображаются
Добавьте на тестовой копии два разных размера одной модели. Если они превращаются в одну строку с увеличенным количеством, проверьте правило объединения позиций. Сравнения только по общей карточке товара может быть недостаточно: необходимо учитывать вариант и значимые опции.
Если в сохранённой корзине варианты различаются правильно, а на странице показаны одинаковые подписи, область поиска другая — вывод названия, свойств и изображения. Отдельный признак: выбор верен до перезагрузки, но меняется после неё. Здесь нужно сравнить сохранённые данные с тем, что повторно загружает интерфейс, не объявляя заранее виновным кеш.
Учебный пример и критерии приёмки
Условный каталог содержит футболку с вариантами «синий M», «синий L» и «красный M». Сочетания «красный L» в нём нет. Это учебный пример, а не история клиентского проекта.
Для проверки подготовьте короткую таблицу: действие, ожидаемый вариант, фактический вариант, результат. Включите следующие сценарии:
- «Синий M» добавляется в пустую корзину и остаётся тем же вариантом после перезагрузки.
- После смены размера с M на L добавляется именно «синий L», в том числе при быстром переключении.
- «Синий M» и «синий L» одновременно сохраняются как разные варианты; количество одного не меняет другой.
- Для отсутствующего сочетания «красный L» показывается понятное ограничение, а другой товар не подставляется молча.
- В сохранённом тестовом заказе остаются те же варианты и количества, что подтверждены в корзине.
Повторите эти проверки на телефоне и компьютере, для гостя и тестового пользователя, если магазин поддерживает оба режима. Если корзины объединяются после входа, включите этот переход отдельно. Повторное добавление одного варианта должно соответствовать согласованному правилу магазина, например увеличивать его количество; это другой сценарий, чем объединение разных размеров.
Исправление принимают по совпадению выбора, сохранённой корзины и тестового заказа во всех согласованных сценариях. Успешный одиночный клик и правильная фотография подтверждают лишь часть пути.
Какие риски закрывает проверка
Проверка помогает обнаружить подмену варианта до сборки заказа, ошибочное объединение позиций и ситуацию, когда экран выглядит правильно, но в заказ записаны другие свойства. Она также отделяет ошибку данных от ошибки интерфейса: это позволяет ограничить доработку конкретным участком.
Результат относится к проверенным сочетаниям и способам покупки. Он не доказывает исправность всего каталога, обмена с учётной системой или оформления заказа. Если одновременно пропадают товары, расходятся суммы и теряются заказы, нужен более широкий разбор; для OpenCart этот сценарий рассмотрен в материале об ошибках каталога и заказа.
Где заканчивается самостоятельная проверка
Владелец может описать шаги, сравнить видимые свойства и собрать контрольные сочетания. Если своя команда умеет проследить запрос и повторить ошибку на копии, этой таблицы достаточно для постановки внутренней задачи.
Изменение обработчика корзины, правил объединения или связей каталога требует разработчика и проверки соседних сценариев. Не отключайте все модули на рабочем магазине и не пересоздавайте предложения массово: это может затронуть сохранённые корзины, заказы и обмен.
Что запросить у подрядчика
Передайте URL карточки, выбранные свойства, ожидаемый и фактический результат, последовательность действий, устройство и время наблюдения. Добавьте версии платформы и затронутых расширений, если они известны, а также сведения о последней правке или загрузке каталога.
Запросите результат, который можно проверить:
- точку первого расхождения и подтверждающий пример без данных покупателей;
- список изменённых настроек или участков кода;
- протокол проверки контрольных сочетаний до и после исправления;
- порядок выпуска и возврата изменений, включая обращение с уже сохранёнными корзинами;
- перечень непроверенных способов покупки и оставшихся ограничений.
Не передавайте в открытой переписке cookies, токены, полную запись сетевых запросов или реальные заказы с контактами покупателей. Для описания достаточно очищенных фрагментов и тестовых данных; доступы согласовывают отдельно.
Частые вопросы
Достаточно исправить название в корзине?
Только если подтверждено, что сохранённый вариант и данные заказа верны, а ошибка ограничена отображением. Если неверен сам вариант, новая подпись замаскирует неисправность.
Нужно ли сразу переделывать каталог?
Нет. Сначала установите, где расходится выбор. Локальный обработчик, неверная настройка вариации и ошибочный импорт требуют разных изменений. Масштаб работ определяют после воспроизведения.
Почему ошибка проявляется только на телефоне?
Мобильный шаблон или быстрый просмотр могут использовать другой обработчик. Сравните один и тот же набор действий и отправленные данные на двух устройствах. Само различие по устройствам ещё не устанавливает причину.
Как это решает OpenStart
OpenStart занимается доработкой форм, каталогов и интеграций. Можно начать с одной неисправности: если причина неясна, сначала согласовать диагностику, затем объём исправления и критерии приёмки. Для задачи с вариантами таким критерием служит сохранение выбранных свойств по всей проверяемой цепочке.
Для оценки полезно описать одну карточку и действия, после которых меняется размер или цвет. Менеджер уточнит детали; состав работ и ожидаемый результат первого этапа согласуют до начала.