Зачастую при работе с отчетами возникает необходимость объединить несколько различных номенклатурных групп в одну общую категорию для более наглядного анализа. Проанализируем типичную ситуацию: у нас есть отчет по продажам, построенный на базе «Универсального отчета», в котором фигурируют три отдельные номенклатурные группы: «Кухонные модули», «Кухонные фасады» и «Фурнитура кухни». Наша задача — сгруппировать их в отчете под единым названием «Кухни». Разберем по шагам все возможные варианты решения этой задачи: от самых простых и «топорных» до методически правильных и гибких.
Первый способ, который часто приходит на ум при модификации отчета в конфигураторе — это прямое прописывание условий в самом запросе. Рассмотрим подробнее этот подход. Мы можем использовать конструкцию ВЫБОР КОГДА, чтобы проверить принадлежность номенклатуры к определенной группе и задать для нее новое имя группировки.
Посмотрим на пример кода, который поможет реализовать такую логику:
ВЫБОР
КОГДА ТаблицаРегистра.Номенклатура.Родитель.Наименование ПОДОБНО "%Кухн%"
ТОГДА "Кухни"
КОГДА ТаблицаРегистра.Номенклатура.Родитель.Наименование ПОДОБНО "%Гостиные%"
ТОГДА "Корпусная мебель"
ИНАЧЕ ТаблицаРегистра.Номенклатура.Родитель.Наименование
КОНЕЦ КАК ГруппаКорпус
Важный нюанс: обратите внимание на использование оператора ПОДОБНО и символов процента % по краям строки поиска. Они позволяют искать вхождение слова в наименовании, что страхует от мелких опечаток или лишних пробелов.
Однако выясним причину, почему такой подход считается «костылем» (hardcode). Если завтра появится новая группа, например, «Столешницы для кухни», которая не попадет под условие, или изменится название существующей группы, отчет перестанет выводить корректные данные. Нам придется снова лезть в конфигуратор и переписывать запрос. Это негибко и требует постоянного вмешательства программиста.
Поскольку современные версии «Универсального отчета» построены на Системе компоновки данных (СКД), мы можем решить проблему максимально элегантно прямо в пользовательском режиме предприятия. Разберем этот способ, так как он оставляет управление настройками в руках самих пользователей.
Этот метод идеален, так как при добавлении новой номенклатурной группы пользователю достаточно будет просто отредактировать список в настройках отчета без написания кода.
Самый простой и логичный вариант с точки зрения архитектуры стандартной 1С — это использование встроенной иерархии справочников. Если элементы концептуально относятся к одной макрогруппе, создайте для них папку (группу) прямо в справочнике номенклатурных групп.
Назовите новую группу «Кухни» и перенесите в нее элементы «Кухонные модули», «Кухонные фасады» и «Фурнитура кухни». После этого в отчете достаточно будет настроить группировку по полю Иерархия или выводить родителя номенклатурной группы. Однако, этот вариант не всегда подходит, если текущая иерархия справочника жестко завязана на другие бизнес-процессы или обмены данными, и ломать ее ради одного отчета нельзя.
Если конфигурация у вас самописная (или есть возможность использовать типовой механизм дополнительных реквизитов и сведений), мы можем расширить структуру справочника.
Создадим новый реквизит для справочника номенклатурных групп, назовем его, к примеру, КатегорияДляОтчетов или Макрогруппа (тип данных — Строка или ссылка на новый справочник). Затем в карточках нужных нам групп заполним этот реквизит значением «Кухни». В настройках универсального отчета мы сможем развернуть поле номенклатурной группы по плюсику, выбрать наш новый реквизит Макрогруппа и сделать группировку именно по нему.
Если вмешиваться в структуру справочника категорически запрещено, проанализируем еще один профессиональный метод — создание непериодического регистра сведений. Назовем его НастройкиГруппировокОтчетов.
НоменклатурнаяГруппа (тип — СправочникСсылка.НоменклатурныеГруппы).СводнаяГруппа (тип — Строка).СводнаяГруппа.Подводя итог, можно сказать, что решение с конструкцией ВЫБОР КОГДА оправдано только как очень быстрое, временное решение. Для создания надежной и масштабируемой системы мы рекомендуем использовать пользовательские поля СКД или механизмы дополнительных реквизитов/регистров сведений.