Обновление 1С без потери доработок: почему «просто нажать обновить» работает не всегда

Приветствую вас, коллеги!

В последних статьях я раз за разом писал одну и ту же фразу: "проверьте, актуальный ли у вас релиз, потому что поддержка нового требования приходит с обновлением". Под ЭТрН, под ФСБУ, под маркировку радиоэлектроники - везде.

И каждый раз мне было немного неловко, потому что за этой фразой скрывается отдельная история. Для одних "обновиться" - это вечер работы. Для других - проект на две недели с риском остановить контору.

Разберемся, от чего это зависит и как понять, в какой ситуации вы))

Самая дорогая недоговоренность в 1С

Есть вещь, которую все, кто работает с 1С, знают, а большинство пользователей - нет.

"Нажать обновить" на типовой базе и на доработанной - это два разных действия. С разной механикой, разным риском и разной ценой.

На типовой это правда кнопка: скачали обновление, применили, перезапустили. Полчаса вместе с бэкапом.

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

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

Узнает он об этом в момент, когда уже нажал.

Три состояния, в которых может быть ваша база

Вот развилка, которая определяет все остальное. Состояний три.

Первое: типовая, объекты не редактируются.

Конфигурация ровно такая, как ее выпустил вендор. Формально это режим "объект поставщика не редактируется".

Обновление: кнопка. Никаких конфликтов, потому что ваших изменений нет.

Второе: доработанная, но на поддержке.

Изменения есть, но база сохранила связь с конфигурацией поставщика. Режим называется "объект поставщика редактируется с сохранением поддержки".

Обновление: возможно, но через разбор конфликтов. Сложность прямо пропорциональна объему доработок. Это нормальное, рабочее состояние - именно так и должна жить доработанная база.

Третье: снята с поддержки.

Связь с конфигурацией поставщика разорвана. Обновления на такую базу автоматически не приходят вообще.

Обновление: только вручную, каждый раз, навсегда.

И вот здесь главное предупреждение всей статьи.

Снять базу с поддержки - быстро и удобно в моменте. Когда надо срочно что-то поправить, а система не дает, самый короткий путь - включить возможность изменения и снять ограничения. Система при этом честно предупреждает, что автоматические обновления станут невозможны. Но предупреждение читают редко, а нажать надо один раз.

В результате я регулярно вижу базы, снятые с поддержки лет пять назад, о которых владелец не знает вообще ничего. Ему когда-то быстро сделали доработку, все заработало, все были довольны. А цена выяснилась потом - когда понадобилось обновиться под новое требование, и выяснилось, что обновления просто не приходят.

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

Как проверить свое состояние за пять минут

Практично. Открываете конфигуратор и смотрите.

Шаг 1. Конфигурация - Поддержка - Настройка поддержки.

Что вы увидите:

• "Конфигурация находится на поддержке" и список объектов с их режимами - хорошо, вы в первом или втором состоянии;
• сообщение, что конфигурация не находится на поддержке - вы в третьем. Это то, что надо знать до всех разговоров про обновление.

Шаг 2. Если на поддержке - посмотрите, сколько объектов в режиме "редактируется с сохранением поддержки". Это и есть объем ваших доработок, выраженный в числе.

Десяток объектов - обновление пройдет спокойно. Сотни - готовьтесь к проекту.

Шаг 3. Посмотрите версию конфигурации: Справка - О программе. И сравните с актуальной на портале релизов.

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

Пять минут. И вы уже знаете, обновление у вас - это вечер или проект. Эти три ответа стоит выяснить до того, как понадобится срочно обновляться под новое требование.

Что происходит при обновлении доработанной базы

Механику стоит понимать, даже если делать будете не вы. Она объясняет, почему это не кнопка.

При обновлении база сравнивает три версии сразу:

1. старая конфигурация поставщика - то, что вендор выпускал в прошлый раз;
2. новая конфигурация поставщика - то, что он выпустил сейчас;
3. ваша текущая конфигурация - с вашими доработками.

Дальше система по каждому объекту решает, что делать.

Если объект вы не трогали - берется новая версия от вендора. Автоматически, без вопросов. Так проходит большинство объектов.

Если объект вы трогали, а вендор нет - остается ваша версия. Тоже без вопросов.

А если объект трогали и вы, и вендор - это конфликт. И вот тут система останавливается и спрашивает вас.

Отсюда и весь расклад по срокам. Обновление доработанной базы - это не "применить файл". Это разбор конфликтов, и его объем зависит не столько от количества ваших доработок, сколько от того, насколько они пересеклись с тем, что менял вендор в этом релизе.

Поэтому сроки и непредсказуемы заранее. Бывает, что база с сотней измененных объектов обновляется за день - вендор в этом релизе трогал другое. А бывает, что база с десятком доработок встает на три дня, потому что доработки были в тех самых модулях, которые вендор переписал.

Три способа разрешить конфликт и цена каждого

Когда система спросила, у вас три варианта. И каждый чем-то платится.

Вариант первый: взять версию поставщика.

Обновление применяется полностью. Ваша доработка в этом месте исчезает.

Иногда это правильно: если вендор реализовал то же самое штатно, ваш костыль больше не нужен. Но решать это надо осознанно, а не потому, что так быстрее.

Вариант второй: оставить свою версию.

Доработка сохраняется. Обновление в этом месте не применяется.

И вот это самая коварная опция. Внешне все хорошо: обновились, доработки на месте, никто ничего не потерял. А внутри у вас теперь объект от прошлого релиза в конфигурации нового. Иногда это работает годами. Иногда ломается сразу же, потому что вендор менял этот объект не просто так, а под изменившуюся логику рядом.

Вариант третий: объединить вручную.

Взять изменения вендора и заново вписать в них свою доработку. Правильный вариант, и самый трудоемкий.

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

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

Почему «мы три года не обновлялись» стоит втрое дороже

Самая частая ситуация из всех. И самая дорогая.

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

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

Плюс сопутствующее:

• обновляться придется через промежуточные версии, а не одним прыжком. Каждый шаг - отдельная операция;
• накопились ошибки, которые вендор давно исправил, а у вас все еще живут;
• человек, который делал доработки, скорее всего, уже не с вами. И документации он не оставил;
• база могла успеть распухнуть и требовать технического обслуживания параллельно.

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

Типичная картина, которую я вижу постоянно: база не обновлялась годами, потому что "работает же и трогать страшно". А потом выходит обязательное требование, срок - месяц, и выясняется, что обновление само по себе занимает две недели. И все это время нельзя ни остановиться, ни откатиться, потому что сроки.

Страшно было трогать регулярно. Стало обязательно трогать в аврале.

Расширения: как больше в это не попадать

А это раздел на будущее. Про то, как не создавать себе эту проблему заново.

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

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

Разница в эксплуатации:

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

Самая частая ошибка - делать прямую доработку там, где хватило бы расширения. Обычно не по расчету, а потому что так привычнее исполнителю.

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

Чего расширением сделать нельзя

Раз обещал честно - вот ограничения. Расширение не универсальное решение.

Расширением не получится:

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

И отдельно: расширение может перестать работать после обновления. Если вендор переименовал или удалил объект, на который расширение ссылается, или переписал структуру базового модуля - расширение отвалится. Поэтому проверять после обновления надо и его тоже.

То есть расширения радикально упрощают жизнь, но не отменяют тестирование.

Порядок безопасного обновления

Коротко, по шагам.

Шаг 1. Бэкап. Полный и проверенный. Не выгрузка в .dt, а настоящая копия. И проверить, что она разворачивается - до обновления, а не после. Про это я писал отдельно, но повторю: бэкап, который не разворачивали, бэкапом не является.

Шаг 2. Определить состояние. На поддержке или нет, сколько доработанных объектов, насколько отстали по версии. Те самые пять минут из начала статьи.

Шаг 3. Обновить копию, а не рабочую базу. Разворачиваете копию рядом и обновляете ее. Все конфликты разбираете там.

Шаг 4. Разобрать конфликты осознанно. По каждому решить, что правильно, а не что быстрее.

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

Шаг 6. Проверить расширения и внешние обработки. Они отваливаются чаще всего, и обнаруживается это позже всего.

Шаг 7. Обновить рабочую базу в нерабочее время. Со старой копией наготове на случай отката.

Шаг 8. Понаблюдать первую неделю. Что-то всплывет, это нормально.

Самое важное в этом списке - третий шаг. Обновлять рабочую базу напрямую, не прогнав на копии, - это то, из чего получаются истории про остановленную контору.

Чек-лист перед тем как нажать

Если вам предлагают обновиться - шесть вопросов, которые стоит задать.

1. Моя база на поддержке? Если нет - обсуждаем не обновление, а возврат на поддержку.
2. Сколько объектов доработано? Это единственный честный измеритель объема.
3. На сколько релизов мы отстали? От этого зависит, будет ли обновление в один шаг.
4. Каким способом будете решать конфликты? Если ответ "оставим ваше" - уточните, почему именно так.
5. Обновление пойдет на копии сначала? Если нет - это не обновление, а лотерея.
6. Кто и как будет проверять после? Список операций и люди, которые их прогонят.

Шесть вопросов. Ответы на них говорят о подходе исполнителя больше, чем цена.

Если делать некому

Как вы помните, я айти-специалист: веду 1С для организаций, собираю и держу серверы.

Чем помогаем:

• смотрим состояние базы и говорим прямо: обновление у вас на вечер или на две недели. До начала работ, а не после;
• возвращаем на поддержку базы, которые когда-то с нее сняли - чтобы дальше обновления приходили нормально;
• обновляем доработанные базы с ручным разбором конфликтов, а не "оставим ваше и поехали";
• переносим доработки в расширения, где это возможно, чтобы следующие обновления стали кнопкой;
• прогоняем на копии и проверяем вместе с вашими людьми до переключения;
• берем на регулярное сопровождение, чтобы обновление было вечером раз в полгода, а не проектом раз в три года;
• сдаем в аренду серверы с поддержкой, где есть где развернуть копию и на чем ее прогнать.

Подробнее про обслуживание: 1c.akernel.ru/services/it-podderzhka

Откройте конфигуратор, посмотрите настройку поддержки и напишите, что там - скажу, чего ждать. Это пять минут и бесплатно)

Читайте также: Ваш бэкап 1С точно рабочий? - обязательное чтение перед любым обновлением. И Календарь дедлайнов 2026-2028 - под какие требования обновляться придется в любом случае.