При активной разработке на платформе 1С:Предприятие 8.3 с использованием механизма расширений программисты часто сталкиваются с ситуацией, когда добавленные реквизиты или изменения форм внезапно «исчезают» из пользовательского режима. Особенно часто это проявляется после выполнения административных действий: загрузки базы из копии (через .dt файл), обновления платформы или изменения основной конфигурации. В конфигураторе все объекты присутствуют, но в режиме Предприятия формы выглядят так, будто расширение не применяется или применяется частично.
В этой статье мы подробно разберем, почему возникает такая рассинхронизация, и рассмотрим пошаговые алгоритмы восстановления нормальной работы расширения.
Рассмотрим ситуацию, упомянутую в обсуждении. Когда мы заимствуем форму из основной конфигурации в расширение, платформа создает копию этой формы, которая хранится внутри расширения. Если после этого в основную конфигурацию или в само расширение добавляются новые реквизиты, заимствованная форма может «не узнать» о них автоматически.
Проанализируем шаги для исправления этой ситуации:
Выясним техническую подоплеку проблемы. Когда расширение добавляет новые реквизиты, платформа создает для них физические поля в таблицах СУБД (SQL) или во внутреннем хранилище файловой базы. При загрузке базы из .dt или восстановлении из бэкапа может возникнуть ситуация, когда файл конфигурации расширения (метаданные) говорит о наличии поля, а физическая таблица DBNames не содержит актуальной информации о нем.
Разберем, как принудительно синхронизировать структуру:
F7 (Обновить конфигурацию базы данных). Это инициирует процесс реструктуризации, в ходе которого платформа обязана проверить соответствие метаданных расширения и реальных таблиц БД.Проанализируем еще один важный аспект — настройки безопасности расширения. Начиная с определенных версий платформы 8.3, расширения по умолчанию могут запускаться в безопасном режиме.
Как это влияет на видимость реквизитов:
Если для расширения установлен флаг «Безопасный режим», доступ к данным может быть ограничен политиками безопасности. При переносе базы на новый сервер или восстановлении из копии, система может посчитать расширение «чужеродным» и заблокировать его работу с данными.
Что необходимо сделать:
Рассмотрим ситуацию с кэшем, которая является «классикой» для платформы 1С. Кэш может быть локальным (на компьютере пользователя) и серверным (в сеансовых данных сервера 1С:Предприятия).
Выясним, как правильно очистить кэш в данном случае:
Локальный кэш: Самый простой способ — удалить базу из списка в пусковом окне 1С и добавить её заново. Это создаст новую папку для временных файлов метаданных.
Серверный кэш: Если база клиент-серверная, очистки локального кэша может быть недостаточно. Необходимо выполнить следующие действия:
Агент сервера 1С:Предприятия.srvinfo (где хранятся данные сеансов).snccntx и reg_XXXX (кроме файлов конфигурации).Это заставит сервер заново скомпилировать формы и описания метаданных расширения.
Иногда корень проблемы лежит не в техническом сбое, а в логике работы системы прав. Проанализируем настройки прав доступа:
Когда вы добавляете реквизит в расширение, платформа автоматически создает для него права. Однако, если после восстановления базы роли пользователей «откатились» или не были корректно сопоставлены, пользователь может просто не иметь прав на просмотр этого реквизита. В этом случае реквизит будет виден в конфигураторе, но полностью скрыт в Предприятии.
Также проверим Функциональные опции. Если ваш новый реквизит в расширении привязан к функциональной опции (даже если она из основной конфигурации), и эта опция после загрузки бэкапа оказалась выключена (в значении Ложь), реквизит исчезнет со всех форм.
Если ни один из вышеперечисленных методов не помог, рассмотрим «катастрофический план», упомянутый в обсуждении: удаление и повторное добавление объектов в расширение.
Внимание: Этот метод опасен потерей данных, если в реквизитах расширения уже накоплена информация! Перед выполнением обязательно сделайте резервную копию.
Алгоритм действий:
.cfe) для подстраховки.JSON или XLS), а после пересоздания объектов загрузит их обратно.Для программной проверки наличия реквизита в расширении можно использовать следующий фрагмент кода:
// Проверим, доступен ли реквизит программно
Попытка
ЗначениеРеквизита = Объект.ИмяВашегоРеквизитаРасширения;
Сообщить("Реквизит доступен. Значение: " + ЗначениеРеквизита);
Исключение
Сообщить("Ошибка доступа к реквизиту расширения: " + ОписаниеОшибки());
КонецПопытки;
Подводя итог, можно сказать, что в большинстве случаев проблема решается либо обновлением заимствованной формы, либо очисткой серверного кэша и отключением безопасного режима. Тщательный анализ этих факторов позволит вам восстановить работоспособность системы без радикальной переделки расширения.