К статье
Практический материал

Администрирование · 9 мин

Ошибка «Данные были изменены или удалены другим пользователем» в 1С: причины и способы решения

Ошибка «Данные были изменены или удалены другим пользователем» в 1С: причины, способы обойти конфликт записи, работа с блокировками, версионирование и профилактика.

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

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

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

Что означает ошибка и как работает проверка версий

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

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

Быстрое решение: перечитать объект и записать заново

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

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

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

Порядок действий при единичном конфликте
  1. 1
    Скопируйте или запомните внесённые в форму изменения
  2. 2
    Закройте форму без сохранения или выполните команду «Перечитать»
  3. 3
    Откройте объект заново и проверьте, что изменил другой пользователь
  4. 4
    Повторно внесите свои правки с учётом чужих изменений
  5. 5
    Запишите объект и убедитесь, что ошибка не повторилась

Как узнать, кто и что изменил

Чтобы понять причину конфликта, включите или откройте журнал регистрации: «Администрирование» → «Обслуживание» → «Журнал регистрации». Отфильтруйте события по нужному объекту за период между открытием формы и попыткой записи — вы увидите пользователя или фоновое задание, которое записало объект.

Если в конфигурации включено версионирование объектов («Администрирование» → «Общие настройки» → «Версионирование объектов»), доступна история изменений: кто, когда и какие реквизиты поменял. Это самый удобный инструмент разбора конфликтов и восстановления затёртых значений.

Проверьте также активные сеансы в консоли кластера (для клиент-серверного режима) или через «Администрирование» → «Активные пользователи». Зависший сеанс с открытой формой объекта способен удерживать устаревшую версию и провоцировать повторные конфликты.

Ошибка у одного пользователя разовоОбычный конфликт версий

Достаточно перечитать объект и записать заново

Ошибка повторяется у многихФоновое задание или обмен перезаписывает объекты

Проверить регламентные задания и планы обмена

Ошибка после обмена даннымиКонфликт версий при синхронизации

Проверить настройки приоритета баз в обмене

Ошибка при закрытой форме другого пользователяЗависший сеанс

Проверить и завершить зависшие сеансы

Если виноваты фоновые задания, обмен или зависшие сеансы

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

При обмене между базами (например, УТ и Бухгалтерия) объект может приезжать из другой системы и перезаписываться в момент редактирования. В настройках синхронизации проверьте приоритеты данных и правила разрешения коллизий: обычно одна база назначается главной для конкретных справочников.

Зависшие сеансы завершайте аккуратно: убедитесь, что пользователь действительно не работает, иначе его несохранённые данные пропадут. В файловой базе сеансы завершаются через список активных пользователей, в клиент-серверной — через консоль кластера серверов 1С.

Чего делать нельзя: опасные способы «обхода»

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

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

Типичные ошибки
01
Прямая правка данных в СУБД в обход 1С — рассинхронизация регистров и потеря поддержки
02
Массовое завершение всех сеансов — потеря несохранённой работы пользователей
03
Отключение версионирования и журнала регистрации — невозможность разобрать повторные конфликты
04
Повторная запись без перечитывания — ошибка возвращается, а чужие изменения игнорируются

Профилактика: как снизить число конфликтов

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

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

Маршрут решения

Как выбрать действие

Ошибка появилась один разПеречитайте объект и запишите заново — этого достаточно
Ошибка повторяется у одного пользователяПроверьте его зависшие сеансы и привычку держать формы открытыми
Ошибки совпадают по времени с расписаниемПеренастройте регламентные задания на нерабочие часы
Ошибки после синхронизацииНастройте приоритеты баз и правила разрешения коллизий в обмене

Проверка результата

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

Контрольные точки

Как проверить результат

Запись ранее конфликтного объекта
Норма

Объект записывается без сообщения об ошибке

Тревожный признак

Ошибка возникает снова — источник конфликта не устранён

Журнал регистрации за день
Норма

Нет массовых событий изменения одних и тех же объектов

Тревожный признак

Один сеанс или задание многократно перезаписывает объекты

История версий документа
Норма

Изменения соответствуют реальной работе пользователей

Тревожный признак

Есть изменения от обмена или задания в рабочее время

Итог

Что важно запомнить

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

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

Можно ли отключить проверку «данные изменены другим пользователем»?

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

Ошибка появляется, хотя кроме меня в базе никого нет. Почему?

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

Как восстановить мои данные, если пришлось перечитать объект?

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

Мешает ли открытая форма другим пользователям?

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

Ошибка возникает при обмене между базами. Что делать?

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