Почему исчезает колонка «Наименование» (ФИО) в динамическом списке при программном изменении запроса и как это исправить?

← На главную

В практике разработки на платформе 1С:Предприятие 8.3, особенно в типовых конфигурациях вроде Бухгалтерия предприятия 3.0, часто возникает необходимость программно модифицировать динамические списки. Типичный сценарий: при открытии формы выбора сотрудников (например, из документа «Ведомость в банк») система должна добавить дополнительные кадровые данные, если включен полный кадровый учет. Однако программисты часто сталкиваются с тем, что после выполнения кода колонка Наименование (которой назначен заголовок ФИО) бесследно исчезает с формы. Разберем детально, почему это происходит и как победить эту нестабильность.

Причина 1: Особенности платформы 8.3.10 и оптимизация списков

Начиная с релизов платформы 8.3.10, механизм работы динамических списков был существенно переработан. Были внедрены фоновое считывание данных и новые алгоритмы отрисовки. Это привело к тому, что динамический список стал более чувствителен к соответствию имен полей в запросе и элементов на форме.

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

Причина 2: Конфликт заголовков и имен полей (ФИО vs Наименование)

Выясним интересную закономерность, замеченную разработчиками. Часто на форме выбора сотрудников элементу Наименование программно или в конфигураторе устанавливается заголовок «ФИО». В то же время в конфигурации БП 3.0 существует реквизит справочника ФизическиеЛица с именем ФИО.

Когда срабатывает типовой механизм расширенного кадрового учета, текст запроса перестраивается. Если в новом запросе появляется поле с псевдонимом ФИО (например, из регистра сведений), а на форме уже есть элемент с заголовком ФИО, но привязанный к Список.Наименование, возникает внутренний конфликт имен. Платформа «запутывается» и сбрасывает привязку данных для этого элемента. Рассмотрим, как это выглядит в коде исправления:


// В процедуре ПриСозданииНаСервере после модификации списка
ЭлементНаименование = Элементы.Найти("Наименование");
Если ЭлементНаименование <> Неопределено Тогда
    // Если путь к данным очистился, восстанавливаем его принудительно
    Если ПустаяСтрока(ЭлементНаименование.ПутьКДанным) Тогда
        ЭлементНаименование.ПутьКДанным = "Список.Наименование";
    КонецЕсли;
КонецЕсли;

Причина 3: Влияние кэша пользовательских настроек

Ситуация, когда на демо-базе всё работает, а на рабочей — нет, почти всегда указывает на сохраненные настройки пользователя. 1С сохраняет состояние колонок (ширину, видимость, порядок) в системном хранилище. Если структура динамического списка была изменена программно, платформа пытается применить старые настройки колонок к новому составу полей. Это часто приводит к «фантомному» исчезновению полей.

Разберем шаги для принудительной очистки настроек:

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

В некоторых случаях требуется программная очистка настроек для всех пользователей через справочник «Сохраненные настройки» или использование метода ЭтаФорма.СтандартныеНастройки = Истина; в коде инициализации формы.

Решение через явное обновление компоновщика настроек

Чтобы избежать ситуации, когда форма «не видит» обновленные поля запроса, после установки нового текста запроса в ДинамическийСписок, необходимо синхронизировать объектную модель. Посмотрим на пример кода, который гарантирует корректное обновление:


ТекстЗапроса = "ВЫБРАТЬ
               |    СпрСотрудники.Ссылка КАК Ссылка,
               |    СпрСотрудники.Наименование КАК Наименование,
               |    ФИОФизЛицСрезПоследних.Фамилия + "" "" + ФИОФизЛицСрезПоследних.Имя КАК ФИО_Полное
               |ИЗ
               |    Справочник.Сотрудники КАК СпрСотрудники
               |    ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ФИОФизЛиц.СрезПоследних КАК ФИОФизЛицСрезПоследних ...";

Список.ТекстЗапроса = ТекстЗапроса;

// Критически важный момент: обновление компоновщика
Настройки = Список.КомпоновщикНастроек.ПолучитьНастройки();
Список.КомпоновщикНастроек.ЗагрузитьНастройки(Настройки);

Этот метод заставляет платформу пересчитать доступные поля и корректно сопоставить их с элементами формы, что предотвращает очистку ПутьКДанным.

Проблема основной таблицы

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

Рекомендация: Всегда проверяйте, что после модификации текста запроса свойство Список.ОсновнаяТаблица заполнено корректным именем (например, "Справочник.Сотрудники"). Это гарантирует, что стандартные поля (такие как Наименование или Код) будут распознаны платформой корректно.

Заключение

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