При разработке отчетов с использованием объекта ПостроительОтчета многие разработчики сталкиваются с технической сложностью при попытке изменить вид сравнения отбора на «В списке». Часто это приводит к возникновению ошибок при получении значения, связанных с несовпадением типов данных. В этой статье мы подробно разберем, почему это происходит и как правильно организовать программный код, чтобы ваши отчеты работали стабильно.
Основная сложность работы с ПостроительОтчета заключается в строгой типизации свойств отбора. Когда мы устанавливаем вид сравнения Равно, платформа ожидает, что в свойство Значение будет передано одиночное скалярное значение (например, конкретная ссылка на элемент справочника, строка или число). Однако при переключении режима на В списке, логика работы платформы меняется: теперь она требует передачи коллекции — объекта типа СписокЗначений или Массив.
Ошибка получения значения возникает чаще всего из-за того, что разработчик пытается передать одиночное значение в тот момент, когда в системе уже установлен вид сравнения, требующий списка, или наоборот — пытается изменить вид сравнения, когда в отборе уже сохранено несовместимое значение. Платформа 1С очень чувствительна к последовательности присвоения этих свойств.
Чтобы избежать ошибок, необходимо соблюдать четкий алгоритм при программном добавлении отбора. Рассмотрим по шагам, как это реализовать правильно. Секрет заключается в порядке инициализации: сначала мы создаем элемент, затем устанавливаем вид сравнения, и только в самом конце наполняем и присваиваем значение.
Давайте рассмотрим пример правильного кода:
// 1. Добавляем новое поле в коллекцию отбора
ЭлементОтбора = ПостроительОтчета.Отбор.Добавить("Номенклатура");
ЭлементОтбора.Использование = Истина;
// 2. Сначала задаем вид сравнения «В списке»
ЭлементОтбора.ВидСравнения = ВидСравнения.ВСписке;
// 3. Формируем коллекцию значений, которая необходима для этого типа отбора
СписокОтбора = Новый СписокЗначений;
СписокОтбора.Добавить(ЭлементСправочника1);
СписокОтбора.Добавить(ЭлементСправочника2);
// 4. Передаем готовую коллекцию в свойство «Значение»
ЭлементОтбора.Значение = СписокОтбора;
При таком подходе платформа не успевает выполнить проверку на несоответствие, так как в момент изменения вида сравнения Значение еще не содержит конфликтующих данных, а при наполнении — мы сразу подаем корректный тип коллекции.
Как отметили пользователи, иногда для исправления достаточно просто изменить порядок строк в конфигураторе или коде. Это подтверждает теорию инициализации: когда вы сначала добавляете объект в список отборов, а затем, манипулируя свойствами, добиваетесь того, что ВидСравнения и Значение синхронизируются в нужный момент, ошибка исчезает. Тем не менее, использование явного порядка, приведенного выше, является наиболее надежным методом разработки.
Хотя ПостроительОтчета остается мощным инструментом для решения определенных задач в обычных формах, стоит помнить, что это устаревающий объект. Если вы работаете на платформе 1С:Предприятие 8.3, настоятельно рекомендуется осваивать Систему Компоновки Данных (СКД).
Преимущества перехода на СКД при работе с отборами:
СписокЗначений и заботиться о типах. СКД сама понимает, какой вид сравнения выбран, и предоставляет пользователю соответствующий интерфейс (например, удобное окно с флажками для выбора нескольких значений).СКД решаются настройками в макете компоновки.Мы рекомендуем не ограничиваться только изучением построителя, а выделить время на знакомство с СКД — это значительно упростит процесс написания отчетов и снизит количество ошибок в вашем коде.
Проанализировав ситуацию, мы выяснили, что ошибка при работе с отбором в ПостроителеОтчета — это не баг платформы, а особенность типизации объектов. Соблюдая предложенный порядок инициализации (добавление поля -> установка вида сравнения -> присвоение коллекции), вы навсегда избавитесь от подобных проблем. Если же задача требует создания более сложных и гибких отчетов, самым правильным профессиональным решением будет переход на использование СКД.