Отчет по данным справочников

Цель данной статьи – продемонстрировать начинающим программистам 1С пример перехода от простых задач к продукту – инструменту. Всё, что для этого требуется – некоторый уровень познаний в среде 1С, способность к абстрактному мышлению (подразумевается её наличие у каждого, претендующего на то, чтобы быть программистом) и отсутствие лени.

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

Создав по внешнему отчёту на пару-тройку таких запросов, я задумался об автоматизации. Лень, как известно, двигатель прогресса! В результате получился представляемый ниже продукт, который позволяет решать класс подобных задач в любой конфигурации.

Для начала потребовалось сформулировать задачу в более общих терминах, чем конкретная выборка из конкретного справочника. Задача получения выборки на основе списка была решена ещё в первых отчётах. Для этого использовался универсальный объект 1С – ТабличныйДокумент, в который данные переносились через буфер обмена из Excel. Стандартный подход — цикл по строчкам, формирование списка и передача его в качестве параметра в запрос. Появление дополнительных условий потребовало добавления реквизитов в форму обработки и вмешательства программиста в алгоритм. Задачу же хотелось решить так, чтобы продуктом мог пользоваться продвинутый пользователь.

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

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

Затем  встал вопрос, достаточно ли одного условия «И».  Пришла идея добавить «НЕ», используя цвета стиля. Благо, такой приём, как динамически формируемый запрос, позволяет легко это реализовать. В результате колонки ТабДока с цветом особого текста будут означать выборку, в которую НЕ входят элементы списка.

По мере повышения уровня абстракции пришлось решить задачу для реквизитов ссылочного типа. В ТабДоке содержится наименование реквизита, а сама ссылка представляет собой 32-х символьную платформенную кракозябру. При формировании списка для подстановки в динамический запрос этот момент учтён, что позволяет использовать значения других справочников и перечислений в качестве условий формирования исходных данных для выборки.

Но для задания условий вроде «все элементы этого списка, у которых значение реквизита А больше 1 000» ТабДок отчёта ещё не подходил. И это стало следующей задачей. В итоге колонки реквизитов типов Число и Дата позволяют задавать условия с использованием символов сравнения – «<», «>», «=». Решать задачу с анализом формата даты, честно говоря, не стал. Оставил её для обладающих более высоким уровнем абстракции и меньшим уровнем лени. Показалось проще задавать дату в том формате, в котором 1С преобразовывает значение в дату стандартными средствами, а именно «ггггммдд». С гибкостью отчёта по входными данным ситуация меня устроила. На скриншотах приведены примеры разных результатов работы отчёта при разных входных условиях по данным типа "Дата":

 

 

 

 

 

 

 

 

 

Далее встала задача разнообразить выходные данные. Нашлось следующее решение – подключение к данному отчёту других внешних отчётов на СКД. Алгоритм тут универсальный, неоднократно ранее прописанный: получение объекта типа ВнешнийОтчет, получение СхемыКомпоновкиДанных, её компоновка и вывод. Выводить было решено в другой ТабДок формы первого отчёта. Второй отчёт при этом подходе скрыт от пользователя, но данные формируются именно  по его схеме компоновки данных.

Чтобы решение работало, подключаемые отчёты должны обладать следующими свойствами: наборов данных должно быть два, из которых первый типа Объект (в него передаётся выборка данных первого отчёта, содержащая только одно поле «Ссылка» и сформированная динамическим запросом на основании ТабДока с исходными данными) и второй — любого типа. Второй набор данных должен быть связан с первым по полю «Ссылка». Всё!  Для удобства приложен пример «скрытого» отчёта «ОтчётВнутри.erf», который можно скопировать, чтобы он подключался, а менять впоследствии только запрос и настройки его второго набора данных.

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

Поразмыслив и потратив ещё немного времени, я переделал отчёт и под управляемые формы:

Отчёт для УФ тестировался на платформах 8.3.11.2867, на стандартной конфигурации УНФ 1.16.15.39 и на 8.3.15.1489 на стандартной БП 3.0.71.89.

Представленный продукт не претендует на глобальную универсальность, его можно брать за основу и развивать далее. В коде сделаны комментарии, позволяющие быстрее понять смысл написанного. Развитие может быть, например, в виде добавления фильтров по дополнительным реквизитам. В 8.2. их не было, а в управляемых формах я этого делать пока не стал. А можно и не брать отчёт, создав собственный базовый продукт. 

Мне хотелось показать, что даже решение рутинных задач в 1С может, при желании, привести к созданию универсальных программных продуктов, способных облегчить труд разработчика и применимых  для решения более широкого спектра вопросов.

В архиве — отчёты на ОФ и УФ, а также образец подключаемого отчёта.