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