Как обновить 1С, если конфигурация снята с поддержки

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

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

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

Что значит «снята с поддержки» и как оценить объём доработок

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

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

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

Подготовка: копия базы, дистрибутив обновления и доступы

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

Далее нужен дистрибутив новой версии конфигурации. Он скачивается с портала 1С при действующем договоре ИТС либо получается у партнёра. Из комплекта обновления вам понадобится файл конфигурации поставщика (cf) новой версии — именно с ним вы будете сравнивать свою базу.

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

Пошаговое обновление через сравнение и объединение

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

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

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

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

Как переносить доработки в изменённые поставщиком объекты

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

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

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

Сравнение вариантов

Ручное объединение с cf-файлом

Подходит при небольшом числе доработок; требует внимательного разбора конфликтных объектов

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

Оптимально в долгосрочной перспективе: доработки переносятся в расширение, дальнейшие обновления становятся автоматическими; требует разовой работы по переносу

Привлечение специалиста 1С

Оправдано при глубоких доработках ядра (проведение, расчёты); снижает риск потери логики, но требует бюджета

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

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

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

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

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

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

Открытие базы в режиме предприятия

Норма

База открывается без ошибок, версия конфигурации соответствует новому релизу

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

Ошибки при запуске, сообщения о несовместимости — откатитесь на копию и разберите объединение

Проведение документов

Норма

Документы проводятся, движения по регистрам формируются корректно

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

Ошибки в модулях проведения — вероятно, доработки конфликтуют с новым типовым кодом

Работа доработанных механизмов

Норма

Все собственные функции выполняются как до обновления

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

Доработка пропала или работает иначе — она была перезаписана типовым кодом, восстановите из копии

Регламентированная отчётность

Норма

Отчёты формируются и проходят встроенную проверку

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

Ошибки заполнения — проверьте, обновились ли все связанные объекты

Типичные ошибки и ограничения самостоятельной работы

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

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

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

FAQ: частые вопросы об обновлении снятой с поддержки 1С

Можно ли вернуть конфигурацию на поддержку после доработок?

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

Чем обновление снятой с поддержки базы отличается от обычного?

Обычное обновление выполняется автоматически через «Обновление версии программы» в режиме предприятия. Для снятой с поддержки конфигурации этот механизм недоступен: нужен конфигуратор, файл cf нового релиза и ручное сравнение/объединение с разбором каждого изменённого объекта.

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

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

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

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

Можно ли обновиться сразу на несколько релизов вперёд?

Иногда можно, но только если поставщик это явно допускает в описании релиза. Часто обработчики обновления данных рассчитаны на переход с конкретной предыдущей версии, и пропуск промежуточных релизов приводит к незаполненным данным или ошибкам. Безопасный путь — последовательное обновление через промежуточные версии с запуском обработчиков после каждой.

Обязательно ли привлекать специалиста 1С?

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