← На главную

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

Существуют два основных подхода к решению этой проблемы. Выбор зависит от объема введенной информации и количества промежуточных релизов.

Вариант 1. Перенос введенных данных в обновленную копию базы (рекомендуемый)

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

1. Блокировка сеансов: Установим блокировку работы пользователей в рабочей базе через пункт меню Администрирование → Обслуживание → Блокировка работы пользователей или через консоль администрирования кластера серверов 1С.
2. Анализ изменений через Журнал регистрации: Откроем исходную рабочую базу и запустим Журнал регистрации. Настроим отбор по периоду работы пользователей и событиям Данные. Добавление и Данные. Изменение, а также по конкретному пользователю. Это позволит сформировать точный список созданных и отредактированных объектов.
3. Выгрузка и загрузка данных: Воспользуемся универсальной обработкой Выгрузка и загрузка данных XML. Так как обе базы изначально имели общую историю, уникальные идентификаторы (GUID) неизмененных элементов совпадают, что предотвратит появление дублей при загрузке. Выгрузим из старой базы только измененные и добавленные документы и справочники за нужный период, после чего загрузим их в обновленную базу.
4. Проверка и перепроведение: Проверим корректность проведения перенесенных документов и совпадение движений по регистрам.

Вариант 2. Последовательный накат обновлений на рабочую базу через файлы конфигурации (CF)

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

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

Важные предостережения и внешние обработки

Разберем дополнительные нюансы, которые необходимо учитывать:

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

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