Ошибка «Поле объекта не обнаружено» в 1С: как найти причину и исправить

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

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

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

Что означает ошибка и когда она возникает

Платформа 1С:Предприятие выдаёт это сообщение, когда во время выполнения встроенного языка происходит обращение вида Объект.ИмяПоля, а у конкретного значения в переменной Объект такого поля нет. В тексте ошибки обычно указывается имя поля, например: Поле объекта не обнаружено (Организация).

Типичные ситуации, в которых возникает ошибка:

• реквизит справочника или документа переименовали или удалили, а код, обращающийся к нему, не исправили;
• переменная содержит объект другого типа, чем ожидал разработчик (например, вместо ссылки на документ — ссылка на справочник);
• запрос вернул выборку без нужного поля, а код обращается к нему через точку;
• после обновления конфигурации в типовом объекте изменился состав реквизитов, а доработки или расширение обращаются к старому имени;
• обработчик обмена или внешняя обработка рассчитана на другую версию конфигурации.

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

Как найти место ошибки по журналу регистрации и стеку вызовов

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

Если ошибка происходит в фоновом задании, регламентном задании или при обмене, откройте журнал регистрации (в режиме предприятия: Администрирование → Обслуживание → Журнал регистрации), отфильтруйте по уровню «Ошибка» и времени возникновения. В панели «Технологический журнал» или в расшифровке события будет стек вызовов с именами модулей и номерами строк.

По стеку читайте путь снизу вверх: последняя строка — это процедура, где произошло обращение к несуществующему полю, выше — процедуры, которые её вызвали. Откройте указанный модуль в конфигураторе и перейдите к номеру строки (Ctrl+G).

1. 1
   Сохраните полный текст ошибки и стек вызовов из сообщения пользователя или журнала регистрации
2. 2
   Откройте конфигуратор и перейдите в указанный модуль к указанной строке
3. 3
   Определите, к какому объекту идёт обращение через точку и какого типа переменная в этом месте
4. 4
   Проверьте, существует ли поле с таким именем в метаданных этого объекта
5. 5
   Исправьте обращение или добавьте проверку типа и наличия поля
6. 6
   Протестируйте сценарий на копии базы или в отладчике

Проверка поля в конфигураторе и типа переменной

Когда строка найдена, проверьте две вещи: существует ли поле в метаданных и действительно ли переменная содержит объект ожидаемого типа.

Для проверки метаданных откройте дерево конфигурации, найдите объект (справочник, документ, регистр) и посмотрите список реквизитов, включая стандартные реквизиты и табличные части. Обратите внимание на точное написание имени: встроенный язык нечувствителен к регистру, но чувствителен к опечаткам и лишним символам.

Для проверки типа переменной используйте отладчик: поставьте точку останова перед проблемной строкой, запустите сценарий и посмотрите значение в табло (Shift+F9). Если отладка невозможна, временно добавьте в код вывод типа:

Сообщить("Тип переменной: " + ТипЗнч(Объект) + ", значение: " + Объект);

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

Если ТипЗнч(Объект) = Тип("СправочникОбъект.Номенклатура") Тогда
	Артикул = Объект.Артикул;
Иначе
	ВызватьИсключение "Ожидался объект справочника Номенклатура";
КонецЕсли;

Типовые причины и способы исправления

Обращение к реквизиту после обновления конфигурации

Самая частая ситуация у внедренцев: обновили типовую конфигурацию, и доработанный код или расширение перестало работать, потому что поставщик переименовал реквизит. Решение — найти новое имя реквизита в конфигураторе и исправить обращение во всех местах. Используйте глобальный поиск (Ctrl+Shift+F) по старому имени поля, чтобы найти все обращения в модулях.

Поле выборки запроса

Если обращение идёт к выборке из запроса (Выборка.СуммаДокумента), проверьте текст запроса: поле должно быть явно перечислено в списке выборки, а псевдоним должен совпадать с именем, к которому обращается код. При использовании конструкции ВЫБРАТЬ * из временных таблиц состав полей может отличаться от ожидаемого.

Структуры и соответствия

Обращение к несуществующему ключу структуры через точку также даёт эту ошибку. Безопасный вариант — использовать метод Свойство():

Значение = Неопределено;
Если СтруктураПараметров.Свойство("Склад", Значение) Тогда
// работаем со значением
КонецЕсли;

Расширения конфигурации

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

Ошибка после обновления: проверка кэша и реструктуризации

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

Что можно сделать безопасно:

• очистить кэш клиентского приложения — удалить базу из списка и добавить заново, либо очистить каталог кэша пользователя;
• перезапустить сервер 1С или службу агента, если база клиент-серверная;
• выполнить тестирование и исправление информационной базы с проверкой логической целостности на копии.

Если после обновления не была завершена реструктуризация (добавление реквизитов в таблицы СУБД), часть полей может быть недоступна. Проверьте, завершилось ли обновление базы данных полностью: при запуске конфигуратора не должно быть предложения обновить конфигурацию базы данных.

Как предотвратить ошибку при разработке

Несколько практик заметно снижают риск появления этой ошибки в доработанных конфигурациях:

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

Проверить наличие реквизита у объекта программно можно через метаданные:

МетаданныеОбъекта = Объект.Метаданные();
Если МетаданныеОбъекта.Реквизиты.Найти("Комментарий") <> Неопределено Тогда
// реквизит существует
КонецЕсли;

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

После правки убедитесь, что проблема решена полностью, а не замаскирована:

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

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