В 1С-Битрикс пропадают изменения товаров после сохранения: как найти причину

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

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

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

1. Определите, на каком этапе исчезает значение

Выберите поле, которое меняется предсказуемо: например, детальное описание одного товара. Запишите ID элемента, инфоблок, внешний код XML_ID, адрес карточки, время изменения и ожидаемое значение. Если проблема касается варианта товара, отдельно зафиксируйте ID торгового предложения: родительский товар и предложение — разные записи.

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

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

2. Если изменение не сохранилось, проверьте запрос и результат записи

Сообщение в интерфейсе и HTTP 200 ещё не подтверждают, что нужное поле записалось. Разработчик проверяет, было ли новое значение в отправленном запросе, попало ли оно в серверный обработчик и какой результат вернул метод сохранения. Для CIBlockElement::Update документация предусматривает результат true или false, а при ошибке — текст в LAST_ERROR. Нельзя терять эту ошибку и показывать безусловное «Сохранено».

• Поля нет во входных данных. Проверьте имя элемента формы, состояние disabled, JavaScript, выбранную вкладку и фактически отправленный набор полей.
• Теряется часть большой формы. Сравните число и состав отправленных и принятых параметров. В PHP действует ограничение max_input_vars; оно может повлиять на разбор множества полей. Менять лимит следует после подтверждения причины и в конфигурации PHP, обслуживающего сайт, а не только консольной команды.
• Значение дошло до обработчика, но запись отклонена. Изучите права текущего пользователя, проверки обязательных полей, валидацию типа свойства и сообщение API.
• Записалось другое значение. Проверьте обработчики до сохранения, правила преобразования и код, который формирует итоговый массив полей.

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

3. Если данные на месте, проверьте источник витрины и кеш

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

Затем разработчик прослеживает путь вывода: результат компонента, подготовку данных в result_modifier.php, шаблон, AJAX-обновление и композитный HTML. Кеш проверяют на конкретной странице и конкретном блоке. Если его очистка меняет результат, нужно выяснить, почему штатное обновление товара не инвалидирует нужную зависимость.

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

4. Если правка исчезает позже, найдите процесс, который её перезаписал

Составьте короткую хронологию одного товара. Условный пример: в 10:00 менеджер изменил описание; в 10:01 новая форма и витрина показывают правку; в 10:15 выполнен обмен; в 10:16 в административной карточке снова прежний текст. Совпадение по времени делает обмен кандидатом, но причиной его подтверждает состав переданного пакета и фактическая запись этого поля.

Проверьте все источники, которые могут обновлять запись: узлы обмена с 1С, загрузку Excel/CSV, API поставщика, агенты Битрикса, задания cron, обработчики событий и работу других редакторов. Две настройки обмена могут обращаться к одному товару с разными данными. Служебный пользователь или дата изменения элемента дают ориентир, но сами по себе не называют конкретное задание; цены и свойства нужно прослеживать через их собственные операции.

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

Важно различать попытку и успешную запись. Например, OnAfterIBlockElementUpdate вызывается и после неудачной попытки обновления; в обработчике проверяют RESULT и RESULT_MESSAGE. Кроме того, свойства могут меняться отдельными методами, в том числе SetPropertyValuesEx. Одной записи «сработало событие обновления элемента» недостаточно для полного аудита всех изменений каталога.

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

5. Закрепите за каждым полем источник данных

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

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

Не меняйте XML_ID ради сохранения ручного описания и не создавайте второй товар вместо исправления правил. Это затрагивает связи каталога и торговых предложений. Если источников несколько, полезна настройка структуры каталога и правил импорта. Пример задач по развитию каталога и интеграции — кейс Crocotari.

6. Проверьте исправление после повторного и планового запуска

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

1. Ручная правка. Измените выбранное поле и заново откройте административную карточку и витрину. Зафиксируйте результат.
2. Обычное обновление. Выполните на тестовом контуре типичный обмен или импорт. Поля своего источника должны обновиться, защищённая ручная правка — сохраниться.
3. Повтор того же пакета. Проверьте, что повтор не создаёт дубль товара, не очищает поля и не меняет связи предложения с родителем.
4. Полный набор данных. На отдельном контуре проверьте полный режим: правила, работающие только для загрузки изменений, могут оказаться недостаточными.
5. Расписание. После согласованного переноса исправления на рабочий сайт подтвердите поведение после следующего обычного запуска. Повторите проверку для затронутых профилей и вариантов товара.

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

Частые вопросы

Поможет ли полная очистка кеша?

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

Можно ли просто отключить обмен с 1С?

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

Есть ли готовый код, который запретит любые изменения описания?

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