Обновили 1С — и доработки отвалились: почему и как исправить

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

Почему после обновления 1С отваливаются доработки

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

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

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

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

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

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

Как исправить доработки после обновления 1С

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

Сравнение и объединение конфигураций

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

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

Перенос доработки в расширение

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

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

Что делать, если объект несовместим с новой платформой

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

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

Что делать, если ошибка повторяется после каждого обновления

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

Как отличить архитектурную проблему от разовой ошибки

• ✓Доработка ломается второй раз подряд на разных обновлениях
• ✓Правки внесены в общий модуль или форму напрямую, без расширения
• ✓Обновления накатываются сразу на боевую базу, без тестового контура

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

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

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

Как предотвратить потерю доработок при обновлении 1С

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

Несколько практик снижают риск почти до нуля:

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

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

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

Сколько стоит восстановить доработки и что входит в сопровождение

Мы разбираем конфликт по конфигуратору, сравниваем типовую и доработанную версии объекта, переносим логику в расширение там, где это оправдано, и проверяем результат на копии базы перед тем, как отдать её в работу:

1. ✓Разбираем, какие объекты и доработки затронуты обновлением
2. ✓Сравниваем типовую и доработанную версии в конфигураторе
3. ✓Переносим логику в расширение там, где это снизит риск для следующих обновлений
4. ✓Тестируем на копии базы и только потом переносим изменения в боевую

Стоимость такой работы считается по тарифу сопровождения 1С — от 3800 руб/час, точная сумма зависит от того, сколько объектов затронуто и насколько глубоко правка вплетена в типовой код. Разовое восстановление внешнего отчёта обычно укладывается в один-два часа. Слияние нескольких изменённых общих модулей с ручным разбором конфликтов занимает больше — тут важно не экономить на тестовом контуре, иначе следующее обновление повторит ту же историю.

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

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

После обновления 1С пропала автоматическая печатная форма с логотипом. Это навсегда?

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

Можно ли откатить обновление 1С назад, если доработки массово перестали работать?

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

Как понять, какие доработки слетят при следующем обновлении, а какие нет?

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

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

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

Что делать, если своего программиста 1С в штате нет, а доработки слетают регулярно?

Разовое восстановление можно заказать на аутсорсе по тарифу сопровождения 1С — от 3800 руб/час. Если случаи повторяются каждое обновление, разумнее сразу перевести доработки на расширения и завести тестовую копию базы, чтобы не тушить пожар каждый раз заново.