В процессе разработки на платформе 1С:Предприятие часто встречаются ситуации, когда корректный, на первый взгляд, запрос внезапно перестает выполняться с ошибкой Поле не найдено. Особенно часто это происходит при работе с виртуальными таблицами ОстаткиИОбороты или Обороты. Давайте разберем, почему возникает такая ситуация, и как привести код к стандарту, чтобы избежать подобных проблем.
Основная причина заключается в том, как платформа транслирует запрос 1С в запрос к SQL-серверу. Когда мы накладываем сложное условие на измерение в параметрах виртуальной таблицы, платформа ожидает, что это измерение будет задействовано в выборке. Если вы используете конструкцию ВЫБОР КОГДА ... ТОГДА ... ИНАЧЕ ... внутри параметров виртуальной таблицы, это сильно усложняет работу оптимизатора. В определенных версиях платформы или при смене режимов совместимости, оптимизатор может «отбросить» поле, которое не участвует в списке полей ВЫБРАТЬ, даже если оно есть в условиях ГДЕ параметров виртуальной таблицы.
Первым делом проанализируем структуру параметров. Вместо нагромождения конструкций ВЫБОР КОГДА, которые крайне неудобны для платформы, лучше использовать логические операторы И, ИЛИ. Это сделает код чище и понятнее для оптимизатора СУБД.
Рассмотрим, как превратить «кашу» из условий в лаконичный код. Вместо того чтобы писать многоэтажные условия внутри параметров, мы можем переписать их логически:
ВЫБРАТЬ
РасчетыСПокупателями.Основание
ИЗ
РегистрНакопления.РасчетыСПокупателями.ОстаткиИОбороты(
,
&ДатаСреза,
Авто,
,
Основание = &ЛицевойСчет
И (&ВладелецСчета = НЕОПРЕДЕЛЕНО ИЛИ Контрагент = &ВладелецСчета)
И (ТипРасчета = ЗНАЧЕНИЕ(Перечисление.ТипыРасчетов.ЛицевойСчет)
ИЛИ (&ВключатьСчетаСертификатов И ТипРасчета = ЗНАЧЕНИЕ(Перечисление.ТипыРасчетов.Сертификат)))
) КАК РасчетыСПокупателями
Такой подход позволяет платформе однозначно интерпретировать условия, не прибегая к лишним манипуляциям с полями измерений.
Если условие в параметрах виртуальной таблицы принципиально важно для производительности (чтобы СУБД отсекла лишние данные на раннем этапе), то самое надежное решение — это явно выбрать данное измерение в списке полей запроса. Даже если в итоговом отчете оно вам не нужно, его можно скрыть позже.
Разберем это по шагам:
ТипРасчета, Организация, Контрагент) в список полей ВЫБРАТЬ основного запроса.СГРУППИРОВАТЬ ПО.ПОМЕСТИТЬ.Пример использования временной таблицы:
ВЫБРАТЬ
Т.Основание КАК ЛицевойСчет,
СУММА(Т.СуммаОборот) КАК Сумма
ПОМЕСТИТЬ ВТ_Остатки
ИЗ
РегистрНакопления.РасчетыСПокупателями.ОстаткиИОбороты(,, Авто,, Условие = Значение) КАК Т
СГРУППИРОВАТЬ ПО
Т.Основание, Т.ТипРасчета, Т.Организация // Включаем все поля, задействованные в параметрах
;
ВЫБРАТЬ
ЛицевойСчет,
СУММА(Сумма) КАК Остаток
ИЗ
ВТ_Остатки
СГРУППИРОВАТЬ ПО
ЛицевойСчет
Иногда проблема может носить системный характер, связанный с версией платформы. Как показала практика, переход на другой режим совместимости (например, с 8.3.15 на 8.3.14) может временно решить проблему, но это не является правильным путем, так как современные конфигурации требуют актуальных версий платформы для корректной работы механизмов БСП и новых возможностей 1С.
Рекомендации по профилактике:
РежимСовместимости конфигурации. Если он установлен на очень старую версию, это может вызывать конфликты с текущей платформой.Тестирование и исправление (ТиИ) базы данных, включая Пересчет итогов, если запросы к регистрам начинают вести себя непредсказуемо.ВЫБОР КОГДА в параметрах виртуальных таблиц — это «золотое правило» оптимизации запросов 1С.Остатки, но для конкретной задачи вам не требуются остатки (только обороты), используйте виртуальную таблицу Обороты вместо ОстаткиИОбороты. Это упростит задачу оптимизатору и предотвратит ошибки.Подводя итог: если вы столкнулись с ошибкой Поле не найдено, не торопитесь грешить на платформу. Проанализируйте запрос на предмет избыточности условий в виртуальной таблице. Перенос логики в ГДЕ или явное включение полей в группировку практически всегда решает эту задачу.