Как исправить ошибку «поле не найдено Счет.НалоговыйУчет» при формировании ОСВ с показателями БУ и НУ в 1С:Бухгалтерия?

← На главную

При работе в программе 1С:Бухгалтерия КОРП 3.0 (начиная с релизов 3.0.77 и выше) пользователи часто сталкиваются с неприятной технической проблемой: Оборотно-сальдовая ведомость (ОСВ) отказывается формироваться, если в настройках одновременно установлены показатели «БУ» (Бухгалтерский учет) и «НУ» (Налоговый учет). При этом по отдельности данные показатели выводятся абсолютно корректно и без каких-либо ошибок. При попытке совместного вывода система аварийно завершает работу, выдавая диагностическое сообщение: «поле не найдено Счет.НалоговыйУчет».

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

Техническая причина ошибки: оптимизация запросов в СКД

Для того чтобы понять, почему ломается отчет, обратимся к механизмам работы Системы компоновки данных (СКД) и изменениям, которые фирма «1С» внедрила в платформу начиная с версии 8.3.15.

В более старых версиях платформы (8.3.14 и ниже) компоновщик макетов СКД работал по прямолинейному алгоритму. Если в настройках условного оформления отчета фигурировало какое-либо поле (в нашем случае Счет.НалоговыйУчет), платформа принудительно добавляла его в результирующий SQL-запрос к базе данных. Это происходило даже тогда, когда само условное оформление фактически не применялось напрямую ни к одной из колонок в результирующей таблице.

Начиная с версии платформы 8.3.15, разработчики «1С» оптимизировали построение запросов компоновщика для повышения производительности:

Теперь СКД анализирует правила условного оформления. Если поле, участвующее в условии оформления (например, проверка флага НалоговыйУчет у счета), не связано напрямую с оформляемыми полями или список «Оформляемые поля» в настройках оставлен пустым, оптимизатор считает это поле неиспользуемым.
В целях экономии ресурсов СУБД платформа исключает поле Счет.НалоговыйУчет из финального SQL-запроса.
При непосредственном выводе и отрисовке отчета процессор компоновки данных пытается рассчитать условия оформления (чтобы скрыть или отобразить показатели «НУ» для конкретных счетов). Программа ищет в выборке поле Счет.НалоговыйУчет, не находит его и генерирует ошибку.

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

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

Способ 1. Быстрое решение для пользователей (без изменения конфигурации)

Если вам нужно срочно сформировать отчет, а времени на обновление или привлечение программиста нет, воспользуйтесь стандартным механизмом обхода через настройки отчета. Нам необходимо принудительно заставить СКД выгрузить требуемое поле из базы данных.

Выполним следующие шаги:

В форме Оборотно-сальдовой ведомости нажмите кнопку «Показать настройки».
Перейдите на вкладку «Дополнительные поля».
Нажмите кнопку «Добавить».
В открывшемся дереве доступных полей найдите объект Счет, раскройте его структуру, выберите реквизит Налоговый учет (в метаданных это поле соответствует пути Счет.НалоговыйУчет) и нажмите «ОК».
Нажмите кнопку «Сформировать».

Поскольку поле теперь явно добавлено в список выводимых дополнительных полей, оптимизатор СКД больше не сможет исключить его из SQL-запроса. Отчет успешно сформируется со всеми показателями одновременно.

Способ 2. Корректировка настроек условного оформления

Еще один способ исправить ошибку на уровне пользователя — точечно настроить условное оформление отчета, чтобы СКД распознала связь поля с выводом данных:

В настройках ОСВ перейдите на вкладку «Условное оформление».
Найдите предопределенное правило оформления, отвечающее за отображение показателей налогового учета на счетах (обычно оно отключает вывод «НУ» для счетов, на которых налоговый учет не поддерживается законом, например, на некоторых субсчетах).
Откройте свойства этого правила и перейдите в раздел «Оформляемые поля».
Вместо пустого списка принудительно укажите конкретную выводимую колонку (например, Счет). Это свяжет логику оптимизатора, и поле Счет.НалоговыйУчет будет корректно добавлено в выборку запроса.

Способ 3. Решение в Конфигураторе для разработчиков (свойство «Использовать всегда»)

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

Рассмотрим порядок действий в Конфигураторе:

Откройте конфигурацию и найдите отчет «ОборотноСальдоваяВедомость» (или откройте его схему компоновки в расширении).
Откройте основную схему компоновки данных (обычно это макет с именем ОсновнаяСхемаКомпоновкиДанных).
Перейдите на вкладку «Наборы данных».
В таблице полей набора данных найдите поле Счет.НалоговыйУчет (или родительское поле Счет).
В свойствах этого поля найдите колонку «Использовать всегда» (в англоязычном интерфейсе — Always Used) и установите для нее флаг (истина).

Установка этого флага жестко указывает оптимизатору платформы 1С:Предприятие, что данное поле должно присутствовать в результирующем SQL-запросе при любых настройках отчета, независимо от версии совместимости платформы и активности элементов условного оформления.

Способ 4. Программное принудительное добавление поля при компоновке результата

Если отчет формируется программным путем, или у вас есть возможность внедрить код в модуль объекта отчета через расширение, вы можете программно управлять поведением СКД.

Рассмотрим пример кода, который можно поместить в обработчик события ПриКомпоновкеРезультата модуля объекта отчета. Этот код принудительно добавляет служебное оформление, заставляя платформу всегда включать поле Счет.НалоговыйУчет в выборку:


Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка)
    
    // Получаем текущие настройки отчета
    Настройки = КомпоновщикНастроек.Настройки;
    
    // Добавляем новое фиктивное условное оформление для удержания поля в запросе
    НовоеОформление = Настройки.УсловноеОформление.Элементы.Добавить();
    НовоеОформление.Использование = Истина;
    
    // Задаем условие, задействующее наше проблемное поле
    НовыйЭлементОтбора = НовоеОформление.Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
    НовыйЭлементОтбора.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("Счет.НалоговыйУчет");
    НовыйЭлементОтбора.ВидСравнения = ВидСравненияКомпоновкиДанных.Заполнено;
    НовыйЭлементОтбора.Использование = Истина;
    
    // Связываем с оформляемым полем, чтобы оптимизатор СКД не исключил его
    ОформляемоеПоле = НовоеОформление.Поля.Элементы.Добавить();
    ОформляемоеПоле.Поле = Новый ПолеКомпоновкиДанных("Счет");
    ОформляемоеПоле.Использование = Истина;
    
КонецПроцедуры

Этот способ гарантирует работоспособность отчета при любых действиях пользователя с настройками формы и полностью решает проблему совместимости логики СКД платформы версии 8.3.15 и выше.

Способ 5. Изменение режима совместимости конфигурации (Временная мера)

Если конфигурация находится на поддержке с возможностью изменения, и вам не требуются специфические механизмы платформы версий 8.3.15+, можно временно вернуть режим совместимости:

В конфигураторе откройте свойства корневого узла конфигурации.
Найдите свойство «Режим совместимости».
Установите значение «Версия 8.3.14».

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

Мы надеемся, что данный подробный разбор помог вам разобраться в причинах сбоя Оборотно-сальдовой ведомости и выбрать оптимальный путь решения проблемы для вашей информационной базы.