Администрирование · 12 мин
Как отменить групповое изменение реквизитов в 1С 8.3
Способы отменить групповое изменение реквизитов в 1С 8.3: откат через резервную копию, повторная обработка с обратными значениями, восстановление из истории изменений.
Групповое изменение реквизитов — удобная штатная обработка 1С 8.3, которая позволяет массово поменять значения в справочниках и документах. Обратная сторона удобства — одно неверное действие затрагивает сотни и тысячи объектов. При этом в типовых конфигурациях нет кнопки «Отменить» для уже выполненной групповой обработки: изменения записываются в базу сразу и откат транзакции после завершения невозможен.
Тем не менее отменить результат можно несколькими способами: восстановлением из резервной копии, повторным запуском обработки с обратными значениями, использованием истории изменений (если версионирование включено) или точечным исправлением данных. Выбор зависит от того, сколько времени прошло, какие объекты затронуты и велась ли в базе история изменений.
Ниже разобраны все рабочие сценарии с условиями применения, ограничениями и проверкой результата. Прежде чем что-либо делать, зафиксируйте текущее состояние базы — это защитит от ухудшения ситуации.
Почему групповое изменение нельзя отменить штатной кнопкой
Обработка «Групповое изменение реквизитов» (в типовых конфигурациях находится в разделе «Администрирование» → «Обслуживание» → «Корректировка данных», либо доступна через «Все функции») записывает каждый объект отдельной транзакцией. После завершения работы все изменения уже зафиксированы в базе данных, и механизма отката для них не предусмотрено.
Это принципиальное отличие от редактирования одного объекта: там можно закрыть форму без сохранения. В групповой обработке каждый элемент сохраняется по мере прохождения списка, поэтому даже прерывание обработки кнопкой «Прервать» не отменяет уже записанную часть — останутся изменёнными все объекты, обработанные до момента остановки.
Дополнительная сложность: при записи объектов срабатывают подписки на события, обновляются регистры сведений, могут пересчитываться итоги и запускаться регламентные операции. Даже если вернуть сам реквизит в прежнее значение, побочные следствия записи (например, пересчитанные данные в связанных регистрах) автоматически не откатываются.
Первые действия сразу после ошибочной обработки
Главное правило — не запускать новых массовых операций, пока не оценён масштаб. Каждая следующая запись затрудняет разбор ситуации. Откройте журнал регистрации («Администрирование» → «Обслуживание» → «Журнал регистрации») и отфильтруйте события по пользователю и времени выполнения обработки: там видно, какие именно объекты были изменены.
Если обработка ещё выполняется — немедленно нажмите «Прервать». Чем меньше объектов успело записаться, тем проще откат. Зафиксируйте: какой реквизит менялся, какое значение устанавливалось, какой отбор применялся. Эта информация понадобится для обратной обработки.
Сделайте резервную копию базы в текущем состоянии, даже если данные уже испорчены. Копия позволит вернуться к этой точке, если попытка исправления ухудшит ситуацию, и даст возможность сравнить «до» и «после» при проверке результата.
- 1Прервать выполнение обработки, если она ещё идёт
- 2Зафиксировать параметры: реквизит, новое значение, отбор, время запуска
- 3Открыть журнал регистрации и выгрузить список изменённых объектов
- 4Сделать резервную копию текущего состояния базы
- 5Выбрать способ отката: копия, обратная обработка или история изменений
Способ 1. Восстановление из резервной копии
Самый надёжный вариант — вернуть базу к состоянию до обработки, если резервная копия делалась регламентно. Для файловой базы достаточно заменить файл 1Cv8.1CD копией, для клиент-серверной — восстановить базу средствами СУБД (MS SQL, PostgreSQL) из последнего бэкапа.
Ограничение очевидно: вместе с ошибочными изменениями откатится вся работа пользователей, выполненная после создания копии. Поэтому способ оправдан, когда обработка только что завершилась и в базе почти не было другой активности, либо когда масштаб порчи настолько велик, что точечное исправление нереально.
Компромиссный вариант — восстановить копию в отдельную тестовую базу, не трогая рабочую. Из тестовой базы можно выгрузить правильные значения реквизитов (например, через выгрузку в табличный документ или обработку выгрузки/загрузки данных) и затем загрузить их в рабочую базу только для пострадавших объектов. Так вы сохраните работу пользователей и вернёте корректные данные.
Способ 2. Обратная групповая обработка
Если известно, какое значение было до изменения, запустите ту же обработку «Групповое изменение реквизитов» повторно: с тем же отбором объектов, но укажите прежнее значение реквизита. Это самый быстрый способ, когда все затронутые объекты имели одинаковое исходное значение — например, вы массово очистили флаг, который раньше был установлен у всех.
Сложность возникает, когда исходные значения были разными: у части объектов реквизит был заполнен одним значением, у другой — другим или пустым. Тогда единая обратная обработка сотрёт эти различия. В таком случае сначала получите из резервной копии или истории изменений таблицу соответствия «объект → прежнее значение», а затем либо разбейте обработку на несколько запусков с разными отборами, либо используйте обработку с загрузкой значений из таблицы.
После обратной обработки обязательно проверьте результат выборочно: откройте несколько объектов из списка изменённых и сверьте значения с эталонными. Помните, что повторная запись объектов снова сработает в подписках и может изменить связанные данные — для документов это особенно чувствительно.
Сравнение способов отката
Подходит при свежей копии и минимальной работе пользователей после неё. Ограничение: откатываются все данные, а не только пострадавшие реквизиты.
Подходит, когда исходное значение одинаково у всех объектов или известна таблица прежних значений. Ограничение: повторная запись объектов и риск затереть различающиеся исходные данные.
Подходит, если заранее включено версионирование объектов. Ограничение: без включённого версионирования способ недоступен, историю задним числом создать нельзя.
Способ 3. Восстановление через историю изменений (версионирование)
В типовых конфигурациях на платформе 8.3 есть механизм версионирования объектов: «Администрирование» → «Общие настройки» → «История изменений». Если он был включён для нужного вида объектов до ошибочной обработки, откат выполняется просто: откройте объект, перейдите в «История изменений», выберите версию до обработки и восстановите её.
Для массового восстановления в истории изменений предусмотрен отбор по дате и автору изменений: можно найти все версии, созданные ошибочной обработкой, и последовательно восстановить предыдущие. Это трудоёмко при тысячах объектов, но точно сохраняет индивидуальные исходные значения каждого элемента.
Если версионирование не было включено, восстановить из истории не получится — платформа не хранит прежние значения изменённых реквизитов. В этом случае включите историю изменений сейчас, чтобы защититься от повторения ситуации в будущем: отметьте в настройках справочники и документы, которые чаще всего подвергаются групповым обработкам.
Как выбрать способ отката
Способ 4. Точечное исправление по данным из копии
Когда затронуто немного объектов (десятки, а не тысячи), часто рациональнее исправить их вручную. Разверните резервную копию в отдельной базе, откройте в обеих базах один и тот же список и перенесите прежние значения в пострадавшие элементы. Список пострадавших объектов возьмите из журнала регистрации — отбор по времени и пользователю покажет все записи об изменении данных.
Этот способ самый безопасный с точки зрения побочных эффектов: вы контролируете каждый объект, видите связанные данные и не трогаете ничего лишнего. Минус — трудоёмкость при большом количестве элементов и риск пропустить часть объектов, если не сверяться со списком из журнала регистрации.
Как проверить результат отката
После любого способа восстановления выполните контрольную сверку. Сформируйте список объектов, которые изменяла обработка (по журналу регистрации), и проверьте выборочно 5–10 объектов из разных частей списка: значения реквизитов должны совпадать с эталонными из резервной копии.
Дополнительно проверьте связанные данные: если менялись реквизиты документов, убедитесь, что проведение и движения по регистрам соответствуют ожиданиям; если менялись элементы справочников — что отчёты, использующие эти реквизиты, дают прежние результаты. Не забудьте про объекты, которые могли быть изменены подписками на события при записи.
Как проверить результат
Совпадают со значениями из резервной копии
Часть объектов имеет значение ошибочной обработки или пустые реквизиты
Все объекты из списка журнала регистрации восстановлены
Отдельные объекты пропущены или изменены повторно
Отчёты и движения документов соответствуют состоянию до обработки
Расхождения в отчётах, лишние движения по регистрам
Профилактика: как не попасть в ситуацию повторно
Перед любой групповой обработкой делайте резервную копию или хотя бы выгрузку затрагиваемых данных. Обработка «Групповое изменение реквизитов» в типовых конфигурациях сама предупреждает о необратимости — не игнорируйте это предупреждение.
Используйте режим предварительного просмотра: перед изменением обработка показывает список отобранных объектов — проверьте, что в него не попали лишние элементы. Начинайте с узкого отбора на 2–3 объектах, убедитесь в корректности результата, и только потом расширяйте отбор.
Включите версионирование объектов для ключевых справочников и документов, настройте регламентное резервное копирование и разграничьте права: доступ к групповому изменению реквизитов должен быть только у администраторов и опытных пользователей.
Что важно запомнить
Отмены группового изменения реквизитов в 1С 8.3 не существует — только восстановление: из резервной копии, обратной обработкой или из истории изменений. Сразу после ошибки зафиксируйте параметры обработки, сохраните текущее состояние базы и выбирайте способ отката по принципу наименьших потерь. Профилактика — копия перед обработкой и включённое версионирование.
Частые вопросы
Можно ли отменить групповое изменение реквизитов через Ctrl+Z или кнопку «Отменить»?
Нет. Сочетание Ctrl+Z в 1С работает только при редактировании текста в полях ввода. Записанные в базу объекты этим способом не откатываются — изменения уже зафиксированы транзакциями.
Обработка прервалась на середине — что делать с частично изменёнными данными?
Откройте журнал регистрации и отфильтруйте события изменения данных за период работы обработки — так вы получите точный список уже записанных объектов. Дальше применяйте к этому списку любой из способов отката: обратную обработку или восстановление значений из копии.
Где найти обработку «Групповое изменение реквизитов» в типовой конфигурации?
Обычно в разделе «Администрирование» → «Обслуживание» → «Корректировка данных» → «Групповое изменение реквизитов». Если пункта нет, откройте через меню «Все функции» → «Обработки». Точное расположение зависит от конфигурации и её версии.
Восстановит ли откат движения документов, если менялись их реквизиты?
Не автоматически. Обратная запись реквизита не пересоздаёт движения в прежнем виде — при записи документа движения формируются заново по текущим данным. Если движения критичны, перепроведите документы после восстановления реквизитов и сверьте отчёты с эталонными.
Можно ли узнать, кто и когда запустил ошибочную обработку?
Да, в журнале регистрации. Отфильтруйте события по виду «Данные. Изменение» за нужный период — в записях указан пользователь, время и изменённые объекты. Это также поможет составить полный список пострадавших элементов.
Что делать, если резервной копии нет и версионирование не включено?
Остаётся обратная обработка с известными прежними значениями или ручное исправление по данным из печатных форм, отчётов и выгрузок, где фигурировали старые значения. После решения проблемы обязательно настройте регламентное резервное копирование и включите историю изменений для ключевых объектов.