Разработка и Конфигурация · 11 мин
Как обновить нетиповую конфигурацию 1С и не потерять доработки
Как обновить нетиповую конфигурацию 1С без потери доработок: подготовка, сравнение и объединение, перенос изменений, тестирование и типичные ошибки.
Нетиповая конфигурация 1С — это типовое решение (например, «Управление торговлей» или «Бухгалтерия предприятия»), в которое внесены собственные доработки: изменённые документы, новые отчёты, дополнительные реквизиты, переписанные процедуры. Главная сложность обновления такой базы в том, что новый релиз поставщика может конфликтовать с вашими изменениями, и при неправильном объединении доработки будут утеряны или перестанут работать.
Обновить нетиповую конфигурацию можно двумя путями: полуавтоматическим — через стандартную функцию «Поддержка → Обновить конфигурацию» с ручным разбором конфликтов, и ручным — через «Сравнить, объединить с конфигурацией из файла». Выбор зависит от объёма доработок и от того, снята ли конфигурация с поддержки полностью или частично.
Ниже описан рабочий порядок действий: от подготовки и резервной копии до проверки результата. Материал ориентирован на администраторов и внедренцев, которые обновляют базу самостоятельно и хотят понимать, где именно кроются риски.
Что считается нетиповой конфигурацией и как это влияет на обновление
Конфигурация становится нетиповой в трёх ситуациях. Первая — включена возможность изменения при сохранении поддержки: объекты остаются на замке, но вы правите их код и свойства. Вторая — отдельные объекты сняты с поддержки полностью: поставщик больше не обновляет их автоматически, и вся ответственность за них на вас. Третья — конфигурация снята с поддержки целиком, например после глубокой переработки под заказчика.
Узнать статус можно в конфигураторе: «Конфигурация → Поддержка → Настройка поддержки». Если в диалоге видны объекты со значком «изменён» или стоит признак «конфигурация снята с поддержки», стандартное обновление «в один клик» через интернет-поддержку вам недоступно или пройдёт с потерями.
Чем больше объектов изменено, тем дольше и дороже обновление. Практическое правило: если доработок немного и они локальны (пара отчётов, дополнительные реквизиты), обновление займёт несколько часов. Если переписаны ключевые модули проведения документов, закладывайте минимум рабочий день на разбор конфликтов и тестирование.
Подготовка: копия, инвентаризация доработок и тестовая база
Первое действие перед любым обновлением — полная резервная копия. Для файловой базы достаточно скопировать каталог с файлом 1Cv8.1CD или сделать выгрузку в dt через конфигуратор («Администрирование → Выгрузить информационную базу»). Для клиент-серверной базы делайте бэкап средствами СУБД (MS SQL, PostgreSQL) — выгрузка в dt на больших базах идёт долго и не всегда надёжна.
Второй шаг — инвентаризация доработок. Откройте «Конфигурация → Сравнить конфигурации» и сравните рабочую конфигурацию с конфигурацией поставщика. Полученный список различий — это и есть карта ваших доработок. Сохраните её в файл: при объединении с новым релизом вы будете сверяться именно с ней, чтобы ничего не потерять.
Никогда не обновляйте сразу рабочую базу. Разверните копию на отдельном сервере или в отдельном каталоге, выполните всё обновление там, протестируйте и только потом повторите на рабочей базе по готовому сценарию. Это стандартная практика, которая страхует от непоправимых ошибок.
Получение файлов нового релиза
Для обновления вам нужен файл конфигурации поставщика нового релиза — cf-файл, а не только дистрибутив обновления. Возьмите его одним из способов: из комплекта поставки на портале 1С (раздел обновлений для вашей конфигурации), из шаблонов, установленных через setup дистрибутива (обычно каталог tmplts), или выгрузив cf из чистой демо-базы нового релиза.
Проверьте, что версия cf-файла подходит для вашего перехода. Некоторые релизы нельзя ставить «через голову»: поставщик указывает в сопроводительной документации, с каких версий допустимо обновление. Если ваша версия сильно старее, обновляйтесь последовательно через промежуточные релизы — это дольше, но надёжнее, потому что обработчики перехода данных рассчитаны на пошаговый путь.
Объединение конфигураций: как не потерять доработки
Основной инструмент — «Конфигурация → Сравнить, объединить с конфигурацией из файла». Укажите cf-файл нового релиза. Конфигуратор покажет дерево различий: слева ваша конфигурация, справа — новый релиз поставщика. Перед объединением откройте «Настройки» и задайте режим: для объектов, не изменённых вами, подходит «Взять из новой конфигурации поставщика», а изменённые объекты разбирайте вручную.
Объекты, изменённые только поставщиком
Если объект менялся только в новом релизе, а вы его не трогали, просто отмечайте его к объединению с приоритетом новой конфигурации. Таких объектов обычно большинство, и они не создают проблем.
Объекты, изменённые вами и поставщиком одновременно
Это самая ответственная часть. Типичный пример — вы добавили код в модуль проведения документа, а поставщик в новом релизе переписал этот же модуль. Если взять объект целиком из нового релиза, ваша доработка исчезнет. Если оставить свой вариант, вы потеряете изменения поставщика, и документ может работать неправильно с новыми механизмами.
Правильный путь — объединить с приоритетом нового релиза, а затем вручную перенести свои доработки в обновлённый код. Для модулей удобно использовать построчное сравнение: в окне объединения откройте сравнение текстов модулей, найдите свои вставки и перенесите их в новую версию, адаптируя под изменённые процедуры. Здесь и пригодится сохранённая на этапе подготовки карта доработок.
Объекты, снятые с поддержки
Объекты, полностью снятые с поддержки, при объединении по умолчанию не обновляются — поставщик их больше не контролирует. Если поставщик в новом релизе существенно изменил такой объект (например, типовой документ), решайте осознанно: либо оставляете свою версию и принимаете риск рассинхронизации с новыми механизмами, либо берёте типовую и переносите доработки заново.
- 1Сделайте резервную копию и разверните тестовую базу
- 2Сравните рабочую конфигурацию с конфигурацией поставщика и сохраните список доработок
- 3Запустите «Сравнить, объединить с конфигурацией из файла» с cf нового релиза
- 4Неизменённые вами объекты объедините с приоритетом нового релиза
- 5Изменённые объекты разберите вручную: построчно перенесите доработки в новый код
- 6Выполните «Обновить конфигурацию базы данных» и дождитесь обработчиков обновления
- 7Протестируйте ключевые операции и только затем повторите всё на рабочей базе
Обновление конфигурации базы данных и обработчики перехода
После объединения выполните «Обновить конфигурацию базы данных» (клавиша F7 в конфигураторе). Если структура данных изменилась — добавлены реквизиты, измерения, табличные части — платформа выполнит реструктуризацию. На больших базах она может занять часы, поэтому на рабочей базе планируйте обновление на нерабочее время и предупредите пользователей.
После реструктуризации при первом запуске в режиме предприятия отработают обработчики обновления данных: перенос значений в новые реквизиты, пересчёт итогов, заполнение служебных регистров. В типовых конфигурациях на БСП это видно в форме «Результаты обновления». Не прерывайте этот процесс и не пускайте пользователей в базу до его завершения — иначе получите незаполненные данные и ошибки в отчётах.
Если доработка оформлена как внешняя обработка, отчёт или расширение конфигурации, она переживает обновление без разбора конфликтов. При планировании новых доработок по возможности выносите их в расширения — это резко упрощает и удешевляет все последующие обновления.
Проверка результата и типичные ошибки
После обновления тестовой базы проверьте не только запуск, но и работу доработок. Минимальный набор: открыть формы изменённых документов, провести документы, в модули которых вы вносили код, сформировать доработанные отчёты, выполнить регламентные операции (закрытие месяца, расчёт себестоимости — что актуально для вашей конфигурации). Сверьте цифры в ключевых отчётах с копией до обновления.
Как проверить результат
Все объекты из сохранённой карты доработок присутствуют и работают
Часть доработок исчезла или вызывает ошибки
Документы проводятся без ошибок, движения корректны
Ошибки в модулях, неверные проводки
Показатели совпадают с базой до обновления
Суммы отличаются, появились пустые строки
Все обработчики завершены, статус «успешно»
Есть отложенные или завершённые с ошибкой
Когда обновление лучше поручить специалисту
Самостоятельное обновление оправдано, когда доработки точечные: несколько добавленных реквизитов, внешние печатные формы, пара отчётов, небольшие вставки кода в формы. Такие изменения разбираются в окне объединения быстро и с предсказуемым результатом.
К помощи внедренца стоит прибегнуть, если переписаны типовые механизмы проведения, изменён расчёт зарплаты или налогов, конфигурация снята с поддержки целиком, либо вы пропустили много релизов. В этих случаях цена ошибки — некорректный учёт и налоговые риски — заметно выше стоимости работ специалиста.
Что важно запомнить
Обновление нетиповой конфигурации — это всегда цикл: резервная копия, карта доработок, объединение с cf-файлом нового релиза, ручной перенос изменений в конфликтующих объектах, обновление базы данных, тестирование на копии. Только после успешной проверки сценарий повторяется на рабочей базе.
Частые вопросы
Можно ли обновить нетиповую конфигурацию автоматически через интернет-поддержку?
Нет. Автоматическое обновление в пользовательском режиме работает только для конфигураций на полной поддержке без изменений. Как только включена возможность изменения и внесены правки, обновление выполняется вручную через конфигуратор с разбором конфликтов.
Что делать, если доработка после обновления перестала работать?
Сначала сравните текущий модуль с версией до обновления (из копии базы): вероятно, при объединении ваш код был заменён типовым. Перенесите доработку в новый код заново, учитывая переименованные процедуры и изменённые параметры. Если ошибка в изменившемся типовом механизме, изучите описание релиза — там указаны изменения, влияющие на прикладной код.
Обязательно ли обновлять платформу вместе с конфигурацией?
Да, если новый релиз конфигурации требует более свежую версию платформы — это указано в сопроводительной документации. Сначала установите и проверьте платформу на копии базы, затем обновляйте конфигурацию. Обратный порядок может привести к невозможности запуска.
Сколько времени занимает обновление нетиповой базы?
Зависит от объёма доработок и размера базы. Небольшие правки и средняя база — несколько часов с тестированием. Глубоко переработанная конфигурация или крупная клиент-серверная база с длительной реструктуризацией — один-два рабочих дня. Точную оценку даёт пробное обновление копии.
Что лучше: дорабатывать конфигурацию напрямую или через расширение?
Если задачу можно решить расширением — добавить реквизит, форму, отчёт, переопределить обработчики, — выбирайте расширение. Оно не нарушает поддержку и почти не усложняет обновления. Прямые правки конфигурации оправданы только там, где возможностей расширений недостаточно.
Как откатиться, если обновление прошло неудачно?
Восстановите базу из резервной копии, сделанной до обновления: для файловой базы — верните файл 1Cv8.1CD или загрузите dt, для серверной — восстановите бэкап СУБД. Именно поэтому копию делают до любых действий, а её работоспособность проверяют заранее, а не в момент аварии.