В практике разработки на платформе 1С:Предприятие иногда встречается загадочная ситуация: программист добавляет новый реквизит (например, в справочник или документ), видит его в дереве конфигурации, убеждается, что конфигурация базы данных обновлена, но в режиме «Предприятие» реквизит отсутствует. Он не отображается в формах, его не видят консоли запросов или универсальные подборы, и даже при программном обращении через Объект.ИмяРеквизита платформа выдает ошибку, сообщая, что поле не обнаружено. Рассмотрим подробнее, почему так происходит, и разберем способы решения этой проблемы.
Одной из самых частых причин «исчезновения» реквизита является использование зарезервированных имен. В рассматриваемом нами случае реквизит имел имя Ключ. Проанализируем, почему это название является проблемным. Платформа 1С работает поверх реляционных систем управления базами данных (СУБД), таких как Microsoft SQL Server или PostgreSQL. Слово Key (Ключ) является строго зарезервированным словом в языке SQL. Несмотря на то, что 1С при создании таблиц добавляет префиксы к полям (например, _Fld123), внутренние механизмы платформы при трансляции запросов или при работе с индексами могут входить в конфликт с такими именами.
Выясним, какие еще имена могут привести к подобному поведению. Опытные разработчики рекомендуют избегать следующих названий для реквизитов:
Ключ (Key)Статус (Status)Дата (Date)Индекс (Index)Объект (Object)Элемент (Element)Соединение (Connection)Проверим эту гипотезу простым тестом: попробуем переименовать реквизит Ключ в КлючСвязи или КлючСтроки. Если после обновления конфигурации базы данных реквизит появился в режиме предприятия и стал доступен программно — значит, мы столкнулись именно с ограничением платформы на использование служебных имен.
Если переименование не помогло, проанализируем настройки видимости на уровне метаданных. В 1С существует несколько механизмов, которые могут скрывать данные даже от администратора системы.
Во-первых, разберем влияние Функциональных опций (ФО). Если реквизит привязан к функциональной опции, которая в текущий момент выключена (значение в константе или регистре сведений равно «Ложь»), то этот реквизит будет недоступен в интерфейсе и в запросах. Проверим вкладку «Использование» в свойствах реквизита и убедимся, что поле «Функциональные опции» пустое или соответствующая опция включена.
Во-вторых, рассмотрим права доступа. Даже если у пользователя назначены «Полные права», стоит убедиться в следующем:
Ситуация значительно усложняется, если проблема возникла в периферийной (подчиненной) базе РИБ. Рассмотрим сценарий: в центральной базе реквизит есть и работает, а после обмена в периферийной базе в конфигураторе он виден, а в данных — нет.
Выясним причину такого поведения. Это может быть связано с «битыми» метаданными или неудачным динамическим обновлением. В РИБ синхронизируются не только данные, но и структура конфигурации. Если процесс обновления был прерван или база была некорректно «отвязана» от центральной, внутренние идентификаторы (UUID) реквизитов могут разойтись.
Для решения этой проблемы в периферийной базе выполним следующие шаги:
Иногда платформа «кэширует» старую структуру объектов. Если мы программно обращаемся к реквизиту, которого «нет», попробуем выполнить следующий код в консоли кода, чтобы понять, видит ли его платформа в принципе:
МетаданныеОбъекта = Метаданные.Справочники.ИмяВашегоСправочника;
Для Каждого Реквизит Из МетаданныеОбъекта.Реквизиты Цикл
Сообщить("Найден реквизит: " + Реквизит.Имя);
КонецЦикла;
Если в списке выведенных имен нашего реквизита нет, значит, конфигурация базы данных (DBConfig) фактически не содержит этого поля, несмотря на отображение в дереве конфигуратора. В этом случае может помочь «фиктивное» изменение реквизита (изменить длину строки на 1 символ, сохранить, вернуть обратно и снова сохранить), чтобы заставить платформу инициировать реальное обновление структуры БД.
Подведем итог и сформулируем правила, которые помогут избежать подобных багов в будущем. Проанализируем наш опыт:
Ключ используйте КлючОбъекта, вместо Статус — СтатусЗаказа. Это не только снимет риск конфликтов с СУБД, но и сделает код более читаемым.Соблюдение этих простых правил и понимание того, как платформа 1С взаимодействует с именами объектов, позволит вам сэкономить часы отладки и избежать труднообъяснимых ошибок в работе системы.