Как применить изменения в конфигураторе 1С

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

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

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

Почему правок в конфигураторе недостаточно

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

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

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

Подготовка: резервная копия и проверка конфигурации

Перед любым обновлением конфигурации базы данных сделайте резервную копию. Для файловой базы достаточно выгрузки через «Администрирование → Выгрузить информационную базу» в файл .dt. Для клиент-серверной базы корректнее делать копию средствами СУБД (MS SQL, PostgreSQL), потому что выгрузка .dt на больших базах может занимать часы.

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

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

Базовая процедура: обновление конфигурации базы данных

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

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

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

1. 1
   Сохраните конфигурацию и выполните проверку конфигурации на ошибки
2. 2
   Сделайте резервную копию базы (файл .dt или копия средствами СУБД)
3. 3
   Завершите сеансы пользователей, если нужен монопольный доступ
4. 4
   Выполните «Конфигурация → Обновить конфигурацию базы данных» (F7)
5. 5
   Изучите окно реструктуризации, особенно строки об удалении данных
6. 6
   Подтвердите обновление и дождитесь полного завершения
7. 7
   Запустите 1С:Предприятие и проверьте работу изменённых объектов

Динамическое обновление: когда можно без выхода пользователей

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

Динамическое обновление возможно только тогда, когда правки не ломают совместимость: добавление новых объектов, новых реквизитов, изменение модулей и форм. Изменение типов существующих полей, удаление объектов, правка измерений регистров — это уже причины, по которым платформа потребует монопольный режим и откажет в динамическом обновлении.

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

Обычное или динамическое обновление

Обычное (монопольное)

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

Динамическое

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

Изменения через расширения конфигурации

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

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

Если расширение всё же создаёт собственные объекты с данными (например, свой справочник), потребуется обновление конфигурации БД, но правки основной конфигурации при этом не затрагиваются. Это ключевое преимущество подхода: типовая конфигурация остаётся нетронутой, а обновления от поставщика устанавливаются без конфликтов с доработками.

Контроль результата после обновления

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

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

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

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

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

Запуск 1С:Предприятия

Норма

Режим запускается, изменённые формы открываются без ошибок

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

Ошибки компиляции модулей или «Объект не найден» при открытии

Данные после реструктуризации

Норма

Записи на месте, новые реквизиты заполнены или пусты по замыслу

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

Пропали значения, обрезались строки, потерялись движения

Журнал регистрации

Норма

Нет ошибок в момент обновления и первых минут работы

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

Ошибки реструктуризации, обрывы транзакций, ошибки фоновых заданий

Типичные ошибки и что делать при сбое

Самая частая проблема — сообщение «Конфликт блокировок» или требование монопольного доступа. Причина — активные сеансы пользователей или зависшие фоновые задания. Решение: завершить сеансы через консоль кластера (для серверной базы) или попросить пользователей выйти, затем повторить обновление.

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

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

FAQ

Что делать, если кнопка «Обновить конфигурацию базы данных» неактивна?

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

Можно ли отменить уже применённые изменения?

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

Почему после обновления пользователи не видят изменений?

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

Чем отличается «Сохранить конфигурацию» от «Обновить конфигурацию базы данных»?

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

Опасно ли обновлять конфигурацию на рабочей базе без тестовой копии?

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

Что делать, если реструктуризация идёт слишком долго?

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