Удалили цену в 1С, а B2B-магазин продолжает её показывать: как исправить обмен

Учебная ситуация: в 1С удалили один тип цены товара, обмен завершился без явной ошибки, а B2B-каталог продолжает показывать прежнюю сумму. Ниже рассматривается порядок диагностики и проектирования правил. Статья не утверждает, что любой стандартный компонент использует один универсальный признак удаления или одинаково обрабатывает все версии CommerceML.

Зафиксируйте одну цену и один пакет

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

Цена может храниться отдельно для разных типов, валют и предложений товара. Удаление одной записи не обязано удалять все остальные. Сначала определите точный ключ операции: какой товар или предложение, какой тип цены и какой источник. Иначе проверка может сравнить удалённую оптовую цену с оставшейся розничной.

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

Удаление, отсутствие и ноль имеют разный смысл

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

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

Полная загрузка и частичное обновление требуют разных правил

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

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

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

Где может теряться команда очистки

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

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

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

Удаляйте только согласованную запись

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

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

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

Повтор пакета должен быть безопасным

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

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

Учебный опыт включает последовательности «значение, удаление, повтор удаления» и «старое значение после удаления». Ожидания зависят от принятого договора. Статья не навязывает один механизм очереди; она показывает, какое поведение нужно подтвердить до объявления обмена исправным.

Что должен показать магазин без цены

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

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

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

Какой набор данных нужен для приёмки

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

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

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

Как выпускать изменение без массовой потери цен

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

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

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

Разбор трёх последовательных пакетов

Возьмите учебный товар с двумя типами цены. В первом пакете передайте изменение только одного типа. Второй должен явно прекращать действие этого же типа по поддерживаемому договору. Третий обновляет другой товар и не упоминает первый. Ожидаемое состояние после каждого шага запишите таблицей до запуска.

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

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

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

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

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

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

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

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

Проверяйте удаление под теми же разрешёнными группами, которым показывалась прежняя цена. Административная сессия может видеть другой тип стоимости и скрыть расхождение. Контроль должен относиться к пользовательскому сценарию B2B-каталога.

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

Для смежных решений пригодятся материалы: Цены и скидки из 1С на сайте: причины расхождений | S-WEBS24. Общая схема интеграции определяет владельца цены и способ обмена. Операцию удаления нужно проверить отдельно от создания, изменения и повторного импорта.

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

Можно ли удалять цену, если её нет в XML?

Только если договор подтверждает полноту соответствующего набора и именно такую семантику отсутствия. В частичном пакете отсутствие может означать отсутствие изменения.

Равна ли нулевая цена удалённой?

Нет, это разные состояния. Допустимость нуля и видимость товара нужно согласовать отдельно.

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

• Обмен 1С-Битрикс с 1С: Разделение импорта и экспорта CommerceML; правила частичного обновления нужно проверять в конкретном проекте.
• Цены каталога 1С-Битрикс: Модель каталога предусматривает отдельные операции над ценами; статья не утверждает конкретный обработчик исходного проекта.