← На главную

Представим ситуацию: вы внесли, казалось бы, незначительное изменение в структуру метаданных — например, увеличили длину поля ИНН в справочнике Контрагенты, чтобы корректно вводить данные иностранных партнеров. Однако сразу после этого работа пользователей блокируется. При попытке любого поиска в динамических списках (в журналах приходных или расходных накладных, в списках заказов) система выдает критическую ошибку: "Ошибка при выполнении запроса. Ошибка при получении характеристик для типа: Контрагент".

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

Анализируем причину ошибки

Для начала проанализируем текст самой технической ошибки, которая часто сопровождает это падение: WHERE ИмяПредопределенныхДанных IN (НЕОПРЕДЕЛЕНО). На первый взгляд может показаться, что проблема в коде запроса самого динамического списка. Но, как показывает практика, ошибка воспроизводится даже в пустых списках, где нет никаких сложных условий в Произвольном запросе.

Разберем ситуацию глубже. В современных конфигурациях (таких как УНФ, ERP или УТ) активно используется механизм Характеристик. Этот механизм позволяет динамическому списку "на лету" подтягивать дополнительные реквизиты и сведения, которые хранятся в отдельных таблицах (например, в плане видов характеристик или регистрах сведений). Когда мы меняем длину реквизита ИНН, платформа инициирует обновление кэша метаданных. Если в настройках характеристик справочника Контрагенты допущена неточность или имеется устаревшая связь, механизм генерации SQL-запроса дает сбой.

Проблема заключается в том, что платформа при попытке поиска по строке пытается сопоставить введенный текст со всеми полями, включая характеристики. Из-за "битой" связи система не может определить тип данных характеристики и подставляет в условие сравнения НЕОПРЕДЕЛЕНО, что запрещено на уровне SQL при работе с полями неограниченной длины или несовместимыми типами.

Способ 1: Принудительное обновление характеристик через конфигуратор

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

1. Откроем Конфигуратор и найдем справочник Контрагенты.
2. Перейдем на закладку "Данные" и нажмем кнопку "Характеристики...".
3. В открывшемся окне мы увидим список настроенных характеристик. Обычно там указаны ссылки на ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения или РегистрСведений.СоставСегментовКонтрагентов.
4. Проанализируем записи. Нам необходимо найти ту характеристику, которая вызывает сбой. Как правило, это записи, связанные с сегментами или дополнительными сведениями.
5. Решение: Удалим проблемную строку характеристик, закроем окно, сохраним конфигурацию (F7), а затем добавим эту строку заново вручную. Важно: обычное копирование строки может не помочь, так как оно может сохранить внутренний ошибочный идентификатор. Нужно именно создать запись заново.

Способ 2: Настройка значений отбора видов

Разберем более детальный подход. Часто ошибка ИмяПредопределенныхДанных IN (НЕОПРЕДЕЛЕНО) возникает из-за того, что в окне настройки характеристик не заполнены поля Поле отбора видов и Значение отбора видов.

Посмотрим на пример: если источником характеристик служит регистр сведений, который хранит данные для многих типов объектов (и для контрагентов, и для номенклатуры), системе нужно четко указать, какие именно записи из этого регистра относятся к контрагентам. Если поле Значение отбора видов пустое, платформа может попытаться считать "всё сразу", что и приводит к конфликту типов в динамическом списке.

Для исправления выполним следующие действия:

• В окне редактирования характеристик найдем колонку "Значение отбора видов".
• Укажем там конкретный предопределенный элемент из связанного плана видов характеристик (например, элемент, соответствующий справочнику Контрагенты).
• Если предопределенного элемента нет, его следует создать или проверить, не помечен ли он на удаление в пользовательском режиме.

Способ 3: Очистка серверного кэша и реиндексация

Иногда настройки в конфигураторе верны, но платформа продолжает "помнить" ошибочное состояние метаданных. В этом случае нам поможет полная очистка кэша.

Проанализируем шаги для серверной базы:

1. Остановим службу Агента сервера 1С:Предприятия.
2. Перейдем в каталог srvinfo (обычно это C:\Program Files\1cv8\srvinfo).
3. Найдем папку конкретной информационной базы и удалим в ней содержимое папки snccntx (кэш сеансовых данных).
4. Запустим службу заново.

Для клиентского кэша на локальном компьютере достаточно удалить базу из списка и добавить её снова под тем же именем.

Рекомендация по работе с ИНН иностранных контрагентов

Выясним причину, по которой вообще потребовалось менять длину поля ИНН. Если это связано с необходимостью хранить 14-значные или 18-значные номера налогоплательщиков других стран (например, Казахстана или Китая), важно помнить следующее:

В типовых конфигурациях (УНФ, БП, ERP) реквизит ИНН часто имеет программные проверки в модулях объекта. Код 1С жестко проверяет контрольное число для 10 или 12 цифр. Увеличение длины в метаданных до 14 может "сломать" эти проверки при записи объекта.

Правильный подход: используйте стандартный реквизит НалоговыйНомер (или TIN) для иностранных контрагентов. Он изначально предназначен для строк произвольной длины и не вызывает конфликтов с механизмом характеристик, так как платформа не накладывает на него такие жесткие ограничения, как на стандартный российский ИНН.

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