Товар пропадает из корзины при обмене с 1С: карта причин и проверка

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

Что именно ломается в корзине при обмене с 1С

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

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

Границы задачи в этой статье: действующий магазин на Битрикс с уже настроенным обменом, без переписывания модуля обмена и без изменения логики самой 1С. Мы разбираем, как найти причину на стороне каталога и корзины, какие данные сопоставить и как проверить результат до публикации изменений на рабочем сайте.

Отдельно стоит зафиксировать: корзина может терять позиции не только из-за обмена. Иногда причина — в смене домена, протокола или в кастомной авторизации, которая создаёт нового пользователя. Но если симптом появился сразу после обмена, начинать нужно с сопоставления полей товара и торгового предложения.

Карта данных: какие поля участвуют в привязке

Чтобы понять, почему товар пропадает из корзины при обмене с 1С Битрикс, нужно сначала выписать поля, которые связывают корзину с каталогом. Это и есть карта данных — рабочий артефакт, без которого диагностика превращается в перебор гипотез.

Корзина ссылается на ID элемента и, при наличии, на ID торгового предложения. Ключевые поля для проверки: внутренний ID, ID предложения, артикул, внешний код (ID из 1С), активность, остаток, цена. Обмен может изменить любое из этих полей.

Опаснее всего ситуации, когда 1С присылает товар как новую запись, а старая остаётся неактивной или удаляется. Внешний код при этом может совпадать, но внутренний ID элемента меняется. Корзина, сохранённая ранее, ссылается на старый ID — и позиция перестаёт находиться.

Составьте таблицу соответствия: запишите ID и внешний код товара до и после обмена. Это покажет, изменился ли идентификатор. Затем проверьте активность, остаток и привязку к предложению.

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

Матрица сценариев: что проверить в каждом случае

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

Матрица нужна не для отчётности, а для скорости: она отсекает заведомо неподходящие версии. Если симптом — «позиция видна, но недоступна», проверять удаление записи бессмысленно. Если позиция исчезла полностью, начинать с остатка тоже нерационально.

Заполняйте матрицу по фактам, а не по предположениям. Для каждого сценария фиксируйте, какие данные вы смотрели и что увидели. Это пригодится при приёмке исправления и при следующем обмене.

Порядок диагностики: от симптома к причине

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

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

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

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

Как проверить корзину до и после обмена

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

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

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

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

Учебный пример: позиция исчезла после ночного обмена

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

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

Действия. Сначала выписываем карту данных по этому товару до обмена и после. Оказывается, внешний код товара не изменился, но у торгового предложения сменился внутренний ID: 1С прислала предложение как новую запись, а старая стала неактивной. Корзина ссылалась на старый ID предложения.

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

Результат: позиция снова отображается в тестовой корзине и доступна к заказу. Данные в примере условные и не являются статистикой.

Этот пример показывает типичную развилку: симптом «товар пропал из корзины» может быть следствием смены ID предложения, а не удаления товара. Проверять нужно именно привязку, а не только наличие записи в каталоге.

Типичные ошибки при диагностике

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

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

Третья ошибка — тестировать на рабочей корзине реального покупателя. Это искажает данные и может затронуть заказы. Для проверки нужна отдельная тестовая корзина и понятный план возврата.

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

Пятая ошибка — не фиксировать исходное состояние. Без замера «до» невозможно доказать, что именно изменилось. Простой снимок полей товара и корзины до обмена экономит часы диагностики.

Чек-лист проверки корзины до и после обмена

• Зафиксировать симптом и время: когда позиция стала недоступной или исчезла, совпадает ли это с обменом
• Выбрать один проблемный товар и один условно здоровый для сравнения
• Выписать карту данных: ID, внешний код, артикул, активность, остаток, цена, привязка к предложению
• Проверить, не создаётся ли при обмене дубль записи, а старая не деактивируется
• Сравнить состояние тестовой корзины до и после обмена
• Проверить доступность позиции к заказу, а не только её наличие в списке
• Отдельно проверить ветку авторизации: не совпадает ли потеря с входом покупателя
• Убедиться, что есть резервная копия и план возврата перед изменениями
• Согласовать выводы с ответственным за обмен на стороне 1С
• Повторить проверку после исправления на тестовой корзине

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

Ответственные и границы работ

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

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

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

Если изменения затрагивают оформление заказа, полезно свериться с тем, как устроена доработка интернет-магазина на Битрикс в части сохранности существующих заказов и контрактов внешних систем.

Ограничения и что проверить дополнительно

Не все причины можно подтвердить только по данным каталога. Иногда нужна проверка на стороне 1С: как формируется выгрузка, какие правила присвоения идентификаторов, как обрабатываются предложения. Эти вопросы стоит адресовать ответственному за обмен.

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

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

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