Откат исправления в 1С 8.3: три рабочих сценария
Содержание
Чтобы удалить установленный патч в 1С 8.3, откройте конфигуратор, меню Конфигурация → Расширения конфигурации, выделите расширение с именем вида EF_… и удалите его. Патч в современных типовых конфигурациях — это расширение с назначением «Исправление», поэтому откат не трогает основную конфигурацию и данные.
Если же «патчем» называют обновление релиза или правку, внесённую прямо в конфигурацию, путь другой: восстановление резервной копии .dt или загрузка прежнего файла .cf. Какой способ ваш — зависит от того, как именно исправление попало в базу. С этого и начнём.
Подготовка к откату: что именно вы удаляете
Сначала ответьте себе на три вопроса. От ответов зависит, займёт откат две минуты или полдня.
- 🔍 Как установлено исправление? Автоматически через интернет
-поддержку, вручную из файла
.cfeили обновлением релиза через.cfu. - 🧩 Есть ли в базе другие расширения? Отраслевые доработки, печатные формы, интеграции. Их трогать нельзя.
- 🕒 Что изменилось после установки? Если проблема появилась сразу после патча, откатывать есть смысл. Если раньше — патч ни при чём.
Перед любым действием сделайте копию базы
. Для файловой базы — Администрирование → Выгрузить информационную базу в конфигураторе (файл .dt) или просто копия папки с файлом 1Cv8.1CD при закрытой программе. Для клиент-серверной — выгрузка .dt или резервная копия средствами СУБД.
Без резервной копии откат не начинайте. Удаление расширения необратимо: вернуть его можно только повторной установкой из файла или из сервиса.
Запишите имя и версию патча, который собираетесь удалить. Если проблему решат иначе и исправление понадобится снова, вы будете знать, что именно ставить обратно.
Как устроены патчи в 1С 8.3 и где они хранятся
Фирма-разработчик выпускает исправления между релизами. Раньше срочную ошибку закрывали только новым релизом. Теперь в типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11 и другие) исправление приходит отдельным расширением.
Признаки такого патча:
- 📛 имя начинается с
EF_и дальше идут цифры; - 🏷 в свойствах расширения стоит назначение «Исправление»;
- 🔗 патч привязан к конкретному релизу конфигурации.
Расширение хранится в самой информационной базе, а не в отдельном файле на диске. Поэтому оно одинаково работает у всех пользователей и удаляется один раз, централизованно.
Важное следствие: основная конфигурация патчем не меняется. Снятие с поддержки, объединение, сравнение конфигураций — ничего этого при установке исправления не происходит. Отсюда и простота отката.
| Что установлено | Где лежит | Как откатить |
|---|---|---|
Патч-расширение EF_… | Список расширений базы | Удалить или отключить расширение |
Обновление релиза (.cfu) | Основная конфигурация | Восстановить .dt |
| Ручная правка программиста | Основная конфигурация | Сравнение с поставкой, хранилище, .dt |
| Внешняя обработка-«заплатка» | Справочник дополнительных обработок | Отключить или удалить обработку |
При обновлении на новый релиз установленные исправления для старой версии обычно снимаются автоматически: их содержимое уже входит в новый релиз. Если после обновления в списке остались расширения EF_, значит, это исправления, подходящие и к новой версии.
Способ 1. Удаление патча прямо в программе
Самый быстрый путь не требует конфигуратора. Подходит, если у вас полные права в базе.
- Откройте
Администрирование → Интернет-поддержка и сервисы. - Перейдите к обновлению версии программы. В этом блоке есть ссылка на список установленных исправлений (патчей).
- Выделите нужное исправление и удалите его командой в панели формы.
- Закройте программу у всех пользователей и откройте заново.
Альтернативный путь — общий список расширений: Администрирование → Печатные формы, отчеты и обработки → Расширения. Там видны все расширения базы, включая доработки сторонних разработчиков. Патчи узнаются по имени EF_.
Если не уверены, что дело в патче, не удаляйте его сразу. В списке расширений снимите флажок активности и перезапустите программу. Ошибка ушла — виноват патч. Осталась — включите обратно, ничего не потеряно.
Обратите внимание на настройку автоматической установки исправлений в том же разделе интернет-поддержки. Пока она включена, удалённый патч может прийти снова при следующей проверке обновлений. На время разбирательства автоустановку лучше отключить, а после — вернуть.
Способ 2. Удаление патча через конфигуратор
Если команды в программе нет, ваших прав не хватает или база не запускается из-за патча, работайте через конфигуратор.
- Запустите базу в режиме «Конфигуратор» под администратором.
- Откройте меню
Конфигурация → Расширения конфигурации. - В списке найдите расширение с именем
EF_…. Колонка с назначением покажет «Исправление». - Выделите строку и нажмите кнопку удаления на панели окна.
- Подтвердите действие.
В этом же окне есть флажок «Активно». Снятие флажка отключает расширение без удаления — удобно для проверки гипотезы.
Изменение применяется к базе сразу. Пользователи, которые сейчас работают, продолжат работать со старой версией кода до перезапуска. Программа покажет им сообщение об изменении конфигурации.
Если пользователи не перезапустят сеанс, часть из них будет работать с патчем, часть — без. Удаляйте исправление вне рабочего времени или предупредите всех заранее.
Удаление из командной строки
Для администратора, который обслуживает десятки баз, есть пакетный режим конфигуратора. Команда удаления одного расширения выглядит так:
"C:\Program Files\1cv8\8.3.24.1691\bin\1cv8.exe" DESIGNER /F "D:\Bases\Buh" /N "Администратор" /P "пароль" /DeleteCfg -Extension EF_10012345 /Out "D:\Logs\delete_patch.log"
Для клиент-серверной базы вместо /F укажите /S "сервер\имя_базы". Номер версии платформы в пути замените на свой, имя расширения — на реальное. Результат смотрите в файле лога: при ошибке там будет её текст.
Откат через загрузку предыдущей версии конфигурации
Этот способ нужен, когда «патчем» был не расширение, а обновление релиза. Например, бухгалтер поставил новый релиз, и после него перестал формироваться отчёт.
Правильный путь: восстановление из .dt
- Найдите выгрузку
.dt, сделанную непосредственно перед обновлением. Программа обычно предлагает её создать в мастере обновления. - Убедитесь, что после этой копии в базе не вводили документы. Если вводили — их придётся внести заново.
- В конфигураторе:
Администрирование → Загрузить информационную базу, выберите файл. - Дождитесь окончания загрузки и откройте базу в пользовательском режиме.
Загрузка .dt требует монопольного доступа: все пользователи должны выйти из базы.
Почему опасно загружать старый .cf
Технически можно открыть Конфигурация → Загрузить конфигурацию из файла и выбрать .cf прошлого релиза. Но обработчики обновления уже переписали данные под новую структуру. Старый код может не понять эти данные.
| Способ | Когда подходит | Риски |
|---|---|---|
Удалить расширение EF_ | Патч установлен как расширение | Почти нет; патч ставится заново |
Восстановить .dt | Обновили релиз, после этого не работали | Теряются данные после копии |
Загрузить старый .cf | Только с участием программиста на копии | Ошибки данных, сбой регламентных заданий |
| Ждать следующего релиза | Проблема некритичная | Время, обходные решения |
Загрузку старого .cf поверх обновлённой базы проводите только на копии. Рабочую базу так не откатывают.
Если копии до обновления нет, разумнее не откатываться, а сообщить об ошибке на линию поддержки и дождаться исправления. Часто через несколько дней выходит патч, который закрывает именно вашу проблему.
Ручное удаление изменений в метаданных
Бывает, что программист закрыл ошибку правкой прямо в основной конфигурации: изменил модуль, добавил реквизит, переписал запрос. Потом выяснилось, что правка ломает другое. Тут откат — работа программиста.
Основные приёмы:
- 📦 Хранилище конфигурации. Если база подключена к хранилищу, в истории найдите версию до правки и верните изменённые объекты. Это самый чистый вариант.
- 🔀 Сравнение с поставкой.
Конфигурация → Сравнить конфигурации: основная конфигурация против конфигурации поставщика. Отличия в модулях покажут, что именно поменяли. Объекты, где отличий быть не должно, возвращают к поставочному виду. - 💾 Файл .cf до правки. Если программист сохранял конфигурацию перед изменением, её можно сравнить и объединить с текущей, взяв только нужные объекты.
Реквизиты, добавленные в основную конфигурацию, удаляйте осторожно. Вместе с реквизитом при обновлении конфигурации базы данных удалятся и его значения во всех записях.
Хорошая практика на будущее — делать собственные исправления тоже расширением. Тогда откат сводится к одному действию, а обновление типовой конфигурации проходит без объединения.
После ручной правки не забудьте Конфигурация → Обновить конфигурацию базы данных (F7). Без этого шага изменения останутся только в конфигураторе.
Очистка кэша после отката
Клиент 1С хранит у себя копию метаданных и настроек. После удаления патча старая копия иногда продолжает «помнить» исправленные формы. Симптомы: странные ошибки при открытии форм, форма в старом виде, сообщения о несоответствии.
Порядок очистки на рабочем месте пользователя:
- Закройте все окна 1С на этом компьютере.
- Запустите базу с параметром
/ClearCache. Его можно добавить в поле дополнительных параметров запуска в настройках базы в окне выбора. - Если не помогло — удалите вручную папки кэша. Они лежат в
%APPDATA%\1C\1cv8и%LOCALAPPDATA%\1C\1cv8. Удаляйте только папки с длинными именами из букв и цифр (идентификаторы баз), файлы со списком баз не трогайте.
Пример bat-файла для очистки локального кэша:
@echo off
for /d %%D in ("%LOCALAPPDATA%\1C\1cv8\*-*-*-*-*") do rd /s /q "%%D"
for /d %%D in ("%APPDATA%\1C\1cv8\*-*-*-*-*") do rd /s /q "%%D"
echo Кэш 1С очищен
Маска *-*-*-*-* выбирает только папки-идентификаторы, поэтому список баз и пользовательские файлы останутся на месте.
Серверный кэш в клиент-серверном варианте чистят редко и только при явных признаках. Это требует остановки службы агента сервера 1С.
Остановка службы сервера 1С обрывает сеансы всех пользователей всех баз на этом сервере. Делайте это только в нерабочее время и после предупреждения пользователей.
Проверка работы базы после удаления патча
Удалить исправление мало — нужно убедиться, что база работает, а исходная проблема ведёт себя предсказуемо.
Журнал регистрации — главный инструмент проверки. Откройте его за период после удаления и отберите события с уровнем «Ошибка». Новых ошибок, связанных с объектами из патча, быть не должно.
Если после удаления стало хуже
Иногда исправление закрывало реальную ошибку, и без него проблема возвращается. Варианты:
- 🔁 установить патч заново из сервиса интернет-поддержки или из сохранённого
.cfe; - 🆕 обновить конфигурацию на свежий релиз, где ошибка закрыта по-другому;
- 📨 описать ситуацию в поддержку разработчика: конфигурация, релиз, имя патча, текст ошибки.
Если патч вернулся сам
Значит, сработала автоматическая установка исправлений. Отключите её в разделе интернет-поддержки или дождитесь нового исправления, которое заменит проблемное.