В процессе сопровождения информационных систем на платформе «1С:Предприятие 8.3» разработчики часто сталкиваются с ситуацией, когда после обновления нетиповой (доработанной или отраслевой) конфигурации расширение перестает работать или выдает ошибки при запуске. Одной из самых коварных проблем является исчезновение реквизитов табличных частей, которые были заимствованы в расширение. Рассмотрим подробнее, почему это происходит, как работает механизм обновления и что нужно предпринять для восстановления работоспособности системы.
Проанализируем ситуацию: вы обновляете конфигурацию, и система не выводит документ в список «дважды измененных», но при этом реквизит табличной части просто исчезает. Многих сбивает с толку именно отсутствие объекта в окне сравнения и объединения как конфликтного. Выясним причину этого поведения платформы.
Механизм сравнения и объединения при обновлении оперирует тремя сущностями: конфигурацией поставщика (старой), новой конфигурацией поставщика и вашей основной конфигурацией. Расширение в этом процессе не участвует напрямую. Если вы не вносили изменения в сам документ в основной конфигурации, а добавили логику только в расширении, то с точки зрения системы основная конфигурация полностью совпадает со старой версией поставщика.
Когда в новой версии поставщика разработчик удаляет реквизит, система видит:
Важно понимать, что расширение — это лишь «надстройка». Если фундамент (основная конфигурация) изменился, расширение не может «удержать» объект, который был физически удален из таблиц базы данных основной конфигурации.
Когда мы заимствуем реквизит в расширение, в нем создается ссылка на уникальный идентификатор (UUID) объекта основной базы. Как только реквизит удаляется при обновлении, эта связь становится «битой». Расширение при попытке применения к основной конфигурации выдает ошибку, так как не находит метаданные, на которые оно опирается. Рассмотрим, к чему это приводит:
Разберем, как правильно действовать, если вы обнаружили пропажу реквизита после обновления. Мы будем работать совместно с инструментами конфигуратора.
Шаг 1. Проверка возможности применения.
Не дожидаясь жалоб пользователей, сразу после обновления конфигурации базы данных (клавиша F7), перейдем в меню Конфигурация — Расширения конфигурации. Выделим наше расширение и воспользуемся функцией «Проверка возможности применения». Система сформирует отчет, где будут указаны все потерянные связи.
Шаг 2. Адаптация логики. Выясним, почему поставщик удалил реквизит. Возможно, он был переименован или его функции теперь выполняет другой объект. Если реквизит больше не нужен в типовой логике, нам необходимо:
Шаг 3. Сохранение данных (если реквизит был важен). Если данные из удаленного реквизита необходимы для работы вашей специфики, алгоритм усложняется. Проанализируем пример кода для переноса данных во временную таблицу перед окончательным принятием изменений:
// Пример логики спасения данных перед обновлением
Процедура СохранитьДанныеПередУдалением()
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ Ссылка, НомерСтроки, ЗначениеРеквизита ИЗ Документ.ВашДокумент.ВашаТабличнаяЧасть";
Результат = Запрос.Выполнить().Выгрузить();
Результат.Записать("C:\temp\saved_data.xml");
КонецПроцедуры
В процессе обсуждения подобных проблем часто всплывает вопрос о контексте исполнения кода. Разберем интересную особенность платформы, касающуюся модулей команд. В отличие от модулей формы, где мы часто используем &НаСервереБезКонтекста, в модулях команд доступна только директива &НаСервере.
Выясним причину: в модуле команды нет «контекста формы» (нет данных, которые нужно гонять между клиентом и сервером), поэтому &НаСервере здесь по умолчанию работает максимально эффективно. Платформа просто упростила синтаксис, избавив разработчика от необходимости писать длинную директиву там, где контекста и так нет. Это важно учитывать при переносе логики из форм в команды расширения.
Чтобы минимизировать ручную работу при каждом обновлении, придерживайтесь следующих рекомендаций при проектировании расширений:
1. Используйте уникальные префиксы.
Никогда не называйте новые реквизиты в расширении именами, которые могут появиться у поставщика. Вместо СуммаИтого пишите пр_СуммаИтого. Это гарантирует, что при добавлении похожего реквизита поставщиком у вас не возникнет конфликта имен.
2. Минимальное заимствование. Не заимствуйте объекты целиком. Если вам нужно изменить только один реквизит, заимствуйте только его. Чем меньше связей между основной конфигурацией и расширением, тем легче пройдет обновление.
3. Использование программного создания реквизитов.
В некоторых случаях опытные разработчики предпочитают создавать реквизиты форм программно в коде расширения, что дает больше гибкости, хотя и требует написания дополнительного кода в обработчике ПриСозданииНаСервере.
Заключение
Мы проанализировали ситуацию с удалением объектов метаданных и убедились, что автоматического решения этой проблемы не существует. Расширение — это интеллектуальная собственность, отделенная от конфигурации поставщика, и их синхронизация после структурных изменений — это всегда задача разработчика. Используйте инструменты диагностики платформы и всегда проверяйте расширения перед запуском системы в рабочую эксплуатацию.