При работе в конфигурациях на обычных формах, таких как «Управление торговлей 10.3» или «Управление производственным предприятием 1.3», пользователи часто сталкиваются со специфическим поведением «Универсального отчета». Одной из самых неприятных проблем является невозможность сохранить настройки, если в отборе указано несколько строк для одного и того же поля с видом сравнения «Содержит». В этой статье мы подробно разберем, почему так происходит и какими способами можно обойти это ограничение платформы.
Рассмотрим стандартную ситуацию: нам необходимо отобрать номенклатуру, в наименовании которой встречаются части слов «з/ч», «заказ» или символ «*». В интерфейсе отчета мы добавляем три строки отбора для поля Номенклатура.Наименование, указываем вид сравнения «Содержит» и соответствующие значения. Отчет формируется корректно, условия отрабатывают по логике «ИЛИ».
Однако при попытке сохранить эти настройки и открыть их заново, мы обнаруживаем, что в списке отборов осталась только одна — последняя — строка. Две предыдущие бесследно исчезают. Проанализируем ситуацию с точки зрения архитектуры 1С.
«Универсальный отчет» в старых конфигурациях базируется на объекте ПостроительОтчета. Механизм сохранения настроек в нем реализован через сериализацию коллекции ПостроительОтчета.Отбор. Когда система записывает настройки в хранилище, она часто использует структуру (соответствие), где ключом является имя поля компоновки. Поскольку у всех трех наших строк имя поля одинаковое (например, НоменклатураНаименование), каждая последующая строка при записи просто перезаписывает предыдущую в структуре сохранения. В итоге в файл или базу данных попадает только одно значение.
Если мы не хотим вносить изменения в программный код, нам следует пересмотреть подход к классификации данных. Это самый надежный «методологический» путь. Вместо того чтобы пытаться выуживать нужные позиции по подстроке в наименовании, мы можем использовать механизм Дополнительных свойств объектов.
В отличие от наименования, по свойству мы можем использовать вид сравнения «В списке». Этот вид сравнения отлично сохраняется, так как представляет собой одну строку в коллекции отборов, содержащую массив ссылок. Это полностью решает проблему потери настроек при сохранении.
Если вы являетесь разработчиком и создаете собственный отчет на базе ПостроительОтчета или имеете возможность подправить текст запроса в существующем, можно прибегнуть к хитрости с псевдонимами. Разберем этот метод подробнее.
Построитель отчета воспринимает поля на основе их псевдонимов в секции ВЫБРАТЬ. Мы можем искусственно размножить одно и то же поле:
ВЫБРАТЬ
Номенклатура.Ссылка КАК Номенклатура,
Номенклатура.Наименование КАК Наименование1,
Номенклатура.Наименование КАК Наименование2,
Номенклатура.Наименование КАК Наименование3
ИЗ
Справочник.Номенклатура КАК Номенклатура
Теперь в настройках отчета у нас появится три разных поля для отбора. Поскольку у них разные имена (Наименование1, Наименование2, Наименование3), штатный механизм сохранения запишет их как три независимых ключа. Это позволит нам задать три разных условия «Содержит», и все они будут успешно восстановлены при открытии отчета.
Наиболее современным и правильным решением будет отказ от использования старого ПостроителяОтчета в пользу СКД. В Системе компоновки данных структура хранения настроек принципиально иная. Каждая строка отбора является отдельным элементом коллекции со своим уникальным идентификатором, что позволяет сохранять неограниченное количество условий по одному и тому же полю.
Для конфигураций УТ 10.3 и УПП 1.3 в сообществе разработчиков давно существуют внешние обработки под названием «Универсальный отчет на СКД». Рассмотрим преимущества такого перехода:
Если отчет должен остаться именно в текущем виде, необходимо программно вмешаться в процесс сохранения. Выясним причину сбоя: стандартный код Универсального отчета в процедуре СохранитьНастройки просто выгружает текущий отбор. Нам нужно переопределить это поведение.
Рассмотрим пример логики, которую необходимо реализовать в модуле отчета:
ПостроительОтчета.Отбор в таблицу значений.XML или помещаем в структуру, которая не использует имена полей в качестве ключей.ВосстановитьНастройки) очищаем текущие отборы и программно добавляем строки из сохраненной таблицы значений.Пример программного добавления отбора:
НовыйОтбор = ПостроительОтчета.Отбор.Добавить("Номенклатура.Наименование");
НовыйОтбор.Использование = Истина;
НовыйОтбор.ВидСравнения = ВидСравнения.Содержит;
НовыйОтбор.Значение = "з/ч";
Помните, что при программном добавлении нескольких строк с одним именем поля ПостроительОтчета их объединит, но при правильной реализации цикла восстановления мы сможем заставить систему отобразить их все.
Часто пользователи спрашивают: «Почему нельзя просто сделать Содержит В списке?». Проанализируем ситуацию: на уровне SQL-запроса оператор LIKE (аналог «Содержит») работает с одной строкой. Конструкции LIKE IN ('%А%', '%Б%') в языке запросов 1С и в стандартных СУБД не существует. Система всегда преобразует такие условия в цепочку (Наименование LIKE %А%) ИЛИ (Наименование LIKE %Б%). Именно поэтому каждый элемент поиска требует отдельной строки в интерфейсе отбора.
Подведем итог: если вы столкнулись с тем, что «Универсальный отчет» в УТ 10.3 или УПП 1.3 «забывает» ваши отборы, самым простым и эффективным способом без программирования будет использование дополнительных свойств. Если же вы готовы к небольшим доработкам, то внедрение внешнего отчета на базе СКД навсегда снимет подобные ограничения платформы.