Как исправить ошибку «Тип не может быть выбран в запросе Таб.ДокументРасчетов» при проведении документов в 1С?

При проведении платежных документов, накладных или списаний с расчетного счета пользователи могут внезапно столкнуться с фатальной ошибкой. В журнале регистрации и на экране появляется сообщение: Ошибка при выполнении обработчика - 'ОбработкаПроведения' по причине: {ОбщийМодуль.УправлениеВзаиморасчетами}: Ошибка при вызове метода контекста (Выполнить) по причине: {(7, 2)}: Тип не может быть выбран в запросе <<?>>Таб.ДокументРасчетов. При этом примечательно, что у одного сотрудника документ не проводится, а у коллеги этот же самый документ проводится без каких-либо нареканий. Разберем по шагам, почему возникает эта неполадка и как ее быстро устранить.

Причины возникновения ошибки

Проанализируем ситуацию и выясним причину сбоя. Реквизит ДокументРасчетов представляет собой составной ссылочный тип, объединяющий множество различных документов взаиморасчетов. В типовых конфигурациях при проведении формируется промежуточная таблица значений, которая передается в запрос в виде параметра через конструкцию ПОМЕСТИТЬ ВТ ИЗ &Таб. Ошибка появляется в трех основных случаях:

1. Рассинхронизация кэша метаданных. Это самая частая причина. После динамического обновления конфигурации («демонического обновления») локальный кэш пользователя может содержать устаревшую структуру метаданных, конфликтующую с актуальным составом типов на сервере.
2. Ограничения прав доступа и механизмы RLS. Если у конкретного пользователя нет прав на чтение хотя бы одного из видов документов, включенных в составной тип ДокументРасчетов, либо на эти документы наложено ограничение доступа на уровне записей, платформа не может однозначно обработать типы колонок во временной таблице запроса.
3. Нарушение типизации таблицы значений в коде конфигурации. Если таблица значений перед передачей в запрос не была строго типизирована, либо в колонку попало значение типа Неопределено или объект системного типа, запрос завершится аварийно.

Способ 1. Очистка кэша передобавлением информационной базы

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

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

Способ 2. Использование параметра запуска /ClearCache

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

1. В окне запуска выберем нужную информационную базу и нажмем кнопку Изменить.
2. Будем нажимать «Далее» до последней страницы настроек, где расположено поле «Дополнительные параметры запуска».
3. В поле параметров введем команду: /ClearCache.
4. Нажмем Готово и запустим конфигурацию. Клиентский кэш метаданных автоматически перестроится.

Способ 3. Ручное удаление папок с кэшем на компьютере пользователя

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

1. Полностью завершим все запущенные сеансы платформы 1С:Предприятие через «Диспетчер задач».
2. Нажмем комбинацию клавиш Win + R, введем команду %LOCALAPPDATA%\1C\1cv8 и нажмем «OK».
3. Удалим все каталоги с длинными буквенно-цифровыми именами (шестнадцатеричными хешами).
4. Повторим ту же операцию для пути %APPDATA%\1C\1cv8, также очистив папки с хеш-именами.
5. Запустим 1С заново: система создаст свежий кэш без ошибок.

Способ 4. Очистка серверного кэша при клиент-серверном режиме

Если сбой возникает сразу у группы сотрудников, а индивидуальная чистка пользовательских компьютеров не помогает, очистим кэш на стороне сервера приложений 1С:

1. Остановим системную службу 1C:Enterprise Server Agent.
2. Перейдем в служебную директорию кластера srvinfo (по умолчанию расположена в профиле службы сервера 1С).
3. Найдем и удалим каталоги сеансовых данных и кэша, начинающиеся с snccntx*.
4. Запустим службу 1C:Enterprise Server Agent и проверим работу пользователей.

Способ 5. Проверка прав доступа и доработка запросов (для разработчиков)

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

1. Проверим роли и права RLS: убедимся, что у проблемного пользователя есть права на чтение всех объектов, которые могут выступать в качестве ДокументРасчетов. Если прав на один из документов нет, составной тип не сможет корректно развернуться в запросе.
2. Зададим строгое описание типов таблицы значений: при создании таблицы в коде перед передачей в запрос обязательно зададим типы колонок с помощью объекта ОписаниеТипов. Посмотрим на пример правильной инициализации колонки:

МассивТипов = Новый Массив;
МассивТипов.Добавить(Тип("ДокументСсылка.РеализацияТоваровУслуг"));
МассивТипов.Добавить(Тип("ДокументСсылка.ПоступлениеТоваровУслуг"));

Квалификаторы = Новый ОписаниеТипов(МассивТипов);
ТаблицаВзаиморасчетов.Колонки.Добавить("ДокументРасчетов", Квалификаторы);

Также внутри текста запроса для составных типов рекомендуется использовать явное приведение с помощью конструкции ВЫРАЗИТЬ(Таб.ДокументРасчетов КАК ...). Это исключает передачу неподдерживаемых типов и обеспечивает стабильное выполнение запроса независимо от прав текущего пользователя.