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

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

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

Картина меняется в тот день, когда в базе появляется первая доработка. На платформе 8.3 способов сделать её ровно 3, и именно от выбора зависит, переживёт ли она следующий релиз.

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

Дальше — четыре сценария, в которых всё это перестаёт работать после обновления. Они выглядят для пользователя одинаково («вчера было, сегодня нет»), но причины у них разные, и чинятся они по-разному.

Четыре сценария, в которых доработка отваливается

Первый: правку типовой затёрло обновлением

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

Дальше возможны два исхода, и оба плохие. Если выбрать версию поставщика, ваша доработка исчезает. Если оставить свою, база не получает изменений релиза в этом объекте: например, новую форму отчётности или исправленный расчёт. В типовой «Бухгалтерии» это приводит к тому, что регламентированная отчётность за квартал считается по-старому, а узнают об этом в момент сдачи.

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

Второй: расширение не применилось, потому что объекта больше нет

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

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

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

Третий: перехват метода, который у поставщика изменился

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

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

Четвёртый: внешняя обработка и изменившийся интерфейс

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

Почему «расширение неактивно» — это сработавшая защита

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

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

Что делать, если обновление уже сломало работу

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

1. Остановиться и не чинить на боевой базе. Первый рефлекс — «сейчас быстро поправлю» — и есть главный источник вторых поломок. Пока непонятна причина, любая правка вслепую добавляет ещё одну переменную.
2. Снять точную формулировку ошибки. Не «не работает», а скриншот с полным текстом. «Ошибка применения расширения конфигурации» и «поле объекта не обнаружено» — это разные диагнозы и разное лечение.
3. Проверить список расширений. В режиме предприятия видно, какие подключены и какие из них отключились. Если доработка жила в расширении, вопрос решается здесь и часто за час.
4. Понять, есть ли откат. Если перед обновлением сделали выгрузку базы, возврат к вчерашнему состоянию занимает время восстановления, а не время разработки. Если выгрузки нет — откатываться некуда, и это отдельный разговор про регламент.
5. Развернуть копию и разбираться на ней. Все проверки и правки — на копии, в боевую переносится уже проверенный результат. Как это устроено у нас, мы описали в разделе «Как работаем».

Как сделать, чтобы обновление перестало быть событием

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

• Делать расширениями, а не правкой типовой. Типовая остаётся на поддержке, обновления продолжают проходить штатно, а при несовместимости вы получаете честное сообщение при старте вместо тихого расхождения в цифрах.
• Обновлять сначала на копии. Копия базы, обновление на ней, проверка доработок и ключевых операций — и только потом боевая. Это тот же принцип, по которому мы работаем с копией базы клиента и не трогаем боевую без отдельного разрешения.
• Вести список доработок. Компания без штатного программиста через 2–3 года обычно не может ответить, что у неё вообще доработано. Список из 10 строк — что изменено, зачем, кем и где — экономит дни при каждом обновлении.
• Проверять по одному и тому же сценарию. После обновления прогонять один и тот же короткий список операций: провести типовой документ, сформировать 3 ключевых отчёта, открыть доработанные формы. 5 минут проверки против дня простоя.

Какие именно доработки переживают обновления, а какие требуют переделки под каждый релиз, мы разбираем в разделе «Что делаем» — там по каждому типу работ написано, во что он выливается на длинной дистанции.

Вопросы, которые задают

Можно ли обновлять 1С, если конфигурация снята с поддержки

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

Почему расширение стало неактивным после обновления

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

Сколько времени занимает обновление базы с доработками

Если все доработки сделаны расширениями и они совместимы с релизом — столько же, сколько обычное обновление, то есть от 30 минут. Если типовая правлена, время зависит от числа изменённых объектов: 10 расхождений разбираются за несколько часов, 30–40 — это уже работа на 2–3 дня с обязательной проверкой на копии.

Можно ли откатиться, если после обновления всё сломалось

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

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

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