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