Как обновить нетиповую конфигурацию 1С 8

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

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

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

Оцените объём доработок перед началом

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

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

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

Подготовьте резервную копию и тестовую среду

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

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

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

Обновите конфигурацию поставщика до целевого релиза

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

Если текущий релиз сильно устарел, скачайте с портала поставщика дистрибутивы промежуточных версий. Часть релизов является «кумулятивной» и позволяет перескочить через несколько версий — это указано в файле поставки (обычно в сопроводительной документации к обновлению). Для нетиповой конфигурации проще и надёжнее использовать полный cf-файл целевого релиза: он загружается через «Конфигурация → Загрузить конфигурацию из файла» в отдельную пустую базу.

1. 1
   Создайте пустую базу без данных для эталонной конфигурации
2. 2
   Загрузите в неё полный cf-файл типовой конфигурации целевого релиза
3. 3
   Проверьте версию: Конфигурация → Открыть конфигурацию, сверьте номер релиза в свойствах
4. 4
   Сохраните cf-файл этой конфигурации — он понадобится для сравнения
5. 5
   При необходимости сохраните cf и текущего типового релиза — для трёхстороннего сравнения

Выполните сравнение и объединение конфигураций

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

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

Как разбирать объекты с двойными изменениями

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

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

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

Трёхстороннее сравнение

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

Перенесите доработки и обновите конфигурацию базы данных

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

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

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

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

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

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

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

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

Версия конфигурации

Норма

В «О программе» отображается целевой релиз

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

Номер релиза старый или конфигурация не обновлена в базе данных

Доработанные механизмы

Норма

Все собственные отчёты, обработки и изменённые документы работают как раньше

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

Ошибки «Процедура или функция не обнаружена», пустые печатные формы

Обмены и интеграции

Норма

Обмены выполняются без ошибок в журнале регистрации

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

Ошибки формата, незаполненные объекты при обмене

Права пользователей

Норма

Пользователи входят и работают под своими ролями

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

Нарушение прав доступа при открытии привычных форм

Только после того, как чек-лист пройден полностью, запланируйте обновление рабочей базы: снимите свежую копию, заблокируйте вход пользователей, повторите процедуру (или перенесите готовую конфигурацию через cf-файл с тестового стенда) и выполните обновление конфигурации базы данных.

Типичные ошибки и как их избежать

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

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

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

Доработки только во внешних отчётах и расширенияхОбновляйте штатно через поддержку, после — протестируйте расширения

Изменено несколько модулей и формСравнение и объединение с ручным переносом доработок по списку

Конфигурация переписана более чем наполовинуРассмотрите вариант внедрения новой типовой и переноса доработок в расширение — это упростит будущие обновления

Нет специалиста с опытом объединения конфигурацийНе начинайте самостоятельно — привлеките специалиста 1С, стоимость ошибки выше стоимости работ

Часто задаваемые вопросы

Можно ли обновить нетиповую 1С автоматически через интернет?

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

Что делать, если после обновления пропала доработка?

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

Как упростить будущие обновления нетиповой конфигурации?

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

Сколько времени занимает обновление нетиповой базы?

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

Обязательно ли обновляться через все промежуточные релизы?

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

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

Зафиксируйте полный текст ошибки и не пытайтесь повторно запускать обновление. Восстановите базу из копии, снятой перед обновлением, проанализируйте причину (чаще всего — проблемы с данными, блокировками или правами на уровне СУБД) и устраните её до повторной попытки.