Как обновлять нетиповые конфигурации 1С 8.3

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

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

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

Что считается нетиповой конфигурацией и почему её сложно обновлять

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

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

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

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

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

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

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

Два способа обновления и как выбрать подходящий

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

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

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

Обновление через поддержку

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

Ручное сравнение и объединение

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

Переход через расширения

Не способ обновления, а профилактика: перенос доработок в расширение до обновления резко упрощает будущие объединения. Ограничение: не все изменения (например, правка типовых ролей или глубокая переработка модулей) выразимы расширением.

Пошаговое обновление через механизм поддержки

Работайте в копии базы, запущенной в монопольном режиме. Откройте конфигуратор, перейдите в Конфигурация → Поддержка → Обновить конфигурацию и выберите файл поставки новой версии (.cfu или .cf из шаблона обновления). Платформа загрузит конфигурацию поставщика и запустит окно сравнения.

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

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

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

Как разбирать конфликты при объединении модулей

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

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

Практический приём: помечайте свои доработки в коде комментариями-обёртками с понятной меткой, например // Доработка: причина в начале и конце блока. Тогда при объединении ваши вставки видны сразу, а перенос правок поставщика внутрь таких блоков становится контролируемым. Это самая дешёвая страховка при регулярных обновлениях.

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

Реструктуризация и обработчики обновления данных

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

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

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

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

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

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

Норма

В сведениях о программе отображается новая версия, отложенные обработчики завершены

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

Версия старая или обновление данных «висит» на отложенных обработчиках

Доработки

Норма

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

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

Часть доработок исчезла — при объединении принята версия поставщика

Типовые механизмы

Норма

Проведение документов, закрытие периода, обмены проходят без ошибок

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

Ошибки в типовых операциях — конфликт в модуле разрешён неверно

Печатные формы и отчёты

Норма

Формируются корректно, данные сходятся с дообновлёнными

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

Расхождения в отчётах — не завершены обработчики обновления данных

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

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

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

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

Как снизить стоимость будущих обновлений

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

Для кода, который нельзя вынести в расширение, используйте переопределяемые модули поставщика и подписки на события. Каждую оставшуюся правку документируйте: что изменено, зачем, кем. Через полгода эта запись сэкономит часы анализа при очередном объединении.

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

Частые вопросы

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

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

Что делать, если конфигурация поставщика в базе неизвестна или повреждена?

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

Пропадут ли добавленные реквизиты и документы при обновлении?

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

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

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

Что делать, если после обновления отчёты показывают неверные данные?

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

Нужно ли обновлять платформу вместе с конфигурацией?

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