Использование дополнительных реквизитов и сведений в отчётах
Коротко о доп. реквизитах
Вместо длинного Дополнительные реквизиты и сведения мы будем использовать просто доп. реквизиты. Но так сделано исключительно для краткости. В данном случае мы имеем в виду оба этих механизма.
Хотя между ними и есть отличия – причём, в ряде случаев довольно существенные – но поговорим мы об этом чуть позже.
То, что доп. реквизиты можно использовать в конфигурациях, основанных на БСП, знают все. Все знают, как включить подсистему, как заполнять данные и как настраивать отчёты. На это время тратить не будем.
Вместо этого здесь мы бы хотели показать немного нестандартный сценарий использования доп. реквизитов при работе с отчётами.
Идея механизма состоит в том, чтобы у объекта можно было создать новый реквизит в пользовательском режиме. Без использования расширений и без изменений в конфигурации. То есть доп. реквизит это просто обычный реквизит, такой же, как и все остальные. С некоторыми особенностями, конечно, но всё же.
Создаём реквизит, и он появляется в документах. Если нужно, заполняем его. Если нужно, показываем в отчётах.
Здесь мы обсуждаем противоположный подход. Первичная цель – отчёт. Чтобы его получить, используется реквизит, созданный специально для отчёта.
Что бывает обычно: отчёт нужен для того, чтобы показать реквизит.
Что предлагаем мы: реквизит нужен для того, чтобы получить отчёт.
Пример
Для начала пример (а после устроим разбор полётов).
Продажи падают. Вообще-то у предприятии дела уже не первый день идут как-то нет очень. Всем, будем откровенны, давно пофигу, но вот собственники нервничают. Они решают, что нужно что-то делать, хотя что именно – непонятно. В порядке эксперимента взяли на работу нового маркетолога. Маркетолог оказался личностью весьма креативной. Маркетолог же. Он предложил рассматривать продажи в контексте знаков зодиака менеджеров.
Долги ли, коротко ли, но, как и следовало ожидать, программисту прилетела задача: добавить этот самый знак зодиака в отчёт по продажам. Маркетолог на предыдущей работе уже видел 1С, поэтому даже смог сформулировать свой запрос примерно в таких терминах, что это «должна быть группировка верхнего уровня».
Что делать программисту? Это же типовой отчёт. Не убирать же замочек! Конечно, можно подправить запрос с помощью расширений, но это как-то уж совсем через чур… Из пушки по воробьям. Да и маркетолог непонятно, надолго ли с нами. В общем, на скорую руку программист решил создать в отчёте новое пользовательское поле. И вычислять знак там. Осталось правильно написать функцию. Гугл с Яндексом пришли на помощь (в процессе поисков даже оказалось, что на ИС есть похожие отчёты для БП и ЗУПа!) и в результате получилось примерно так:
Функции для СКД
Выбор
Когда Месяц([Дата рождения]) = 12 И День([Дата рождения]) >= 22 Или Месяц([Дата рождения]) = 1 И День([Дата рождения])
Тогда "Козерог"
Когда Месяц([Дата рождения]) = 11 И День([Дата рождения]) >= 23 Или Месяц([Дата рождения]) = 12 И День([Дата рождения])
Тогда "Стрелец"
Когда Месяц([Дата рождения]) = 10 И День([Дата рождения]) >= 24 Или Месяц([Дата рождения]) = 11 И День([Дата рождения])
Тогда "Скорпион"
Когда Месяц([Дата рождения]) = 9 И День([Дата рождения]) >= 21 Или Месяц([Дата рождения]) = 10 И День([Дата рождения])
Тогда "Весы"
Когда Месяц([Дата рождения]) = 8 И День([Дата рождения]) >= 22 Или Месяц([Дата рождения]) = 9 И День([Дата рождения])
Тогда "Дева"
Когда Месяц([Дата рождения]) = 7 И День([Дата рождения]) >= 21 Или Месяц([Дата рождения]) = 8 И День([Дата рождения])
Тогда "Лев"
Когда Месяц([Дата рождения]) = 6 И День([Дата рождения]) >= 21 Или Месяц([Дата рождения]) = 7 И День([Дата рождения])
Тогда "Рак"
Когда Месяц([Дата рождения]) = 5 И День([Дата рождения]) >= 21 Или Месяц([Дата рождения]) = 6 И День([Дата рождения])
Тогда "Близнецы"
Когда Месяц([Дата рождения]) = 4 И День([Дата рождения]) >= 21 Или Месяц([Дата рождения]) = 5 И День([Дата рождения])
Тогда "Телец"
Когда Месяц([Дата рождения]) = 3 И День([Дата рождения]) >= 21 Или Месяц([Дата рождения]) = 4 И День([Дата рождения])
Тогда "Овен"
Когда Месяц([Дата рождения]) = 2 И День([Дата рождения]) >= 20 Или Месяц([Дата рождения]) = 3 И День([Дата рождения])
Тогда "Рыбы"
Когда Месяц([Дата рождения]) = 1 И День([Дата рождения]) >= 21 Или Месяц([Дата рождения]) = 2 И День([Дата рождения])
Тогда "Водолей"
Иначе "-----"
Конец
Взято отсюда: //infostart.ru/1c/articles/70403/
Программист немного подправил логику и ещё учёл, что это поле для типового отчёт «Валовая прибыль» (там нет поля Дата рождения, но есть поле Менеджер). Теперь получилось как-то так:
Выбор
Когда ГОД([Менеджер.Физическое лицо.Дата рождения]) = 1
Тогда "Не указано"
Когда 31 * МЕСЯЦ([Менеджер.Физическое лицо.Дата рождения]) + ДЕНЬ([Менеджер.Физическое лицо.Дата рождения]) <= 31 * 1 + 20
Тогда "Козерог"
Когда 31 * МЕСЯЦ([Менеджер.Физическое лицо.Дата рождения]) + ДЕНЬ([Менеджер.Физическое лицо.Дата рождения]) <= 31 * 2 + 19
Тогда "Водолей"
Когда 31 * МЕСЯЦ([Менеджер.Физическое лицо.Дата рождения]) + ДЕНЬ([Менеджер.Физическое лицо.Дата рождения]) <= 31 * 3 + 20
Тогда "Рыбы"
Когда 31 * МЕСЯЦ([Менеджер.Физическое лицо.Дата рождения]) + ДЕНЬ([Менеджер.Физическое лицо.Дата рождения]) <= 31 * 4 + 20
Тогда "Овен"
Когда 31 * МЕСЯЦ([Менеджер.Физическое лицо.Дата рождения]) + ДЕНЬ([Менеджер.Физическое лицо.Дата рождения]) <= 31 * 5 + 21
Тогда "Телец"
Когда 31 * МЕСЯЦ([Менеджер.Физическое лицо.Дата рождения]) + ДЕНЬ([Менеджер.Физическое лицо.Дата рождения]) <= 31 * 6 + 21
Тогда "Близнецы"
Когда 31 * МЕСЯЦ([Менеджер.Физическое лицо.Дата рождения]) + ДЕНЬ([Менеджер.Физическое лицо.Дата рождения]) <= 31 * 7 + 22
Тогда "Рак"
Когда 31 * МЕСЯЦ([Менеджер.Физическое лицо.Дата рождения]) + ДЕНЬ([Менеджер.Физическое лицо.Дата рождения]) <= 31 * 8 + 21
Тогда "Лев"
Когда 31 * МЕСЯЦ([Менеджер.Физическое лицо.Дата рождения]) + ДЕНЬ([Менеджер.Физическое лицо.Дата рождения]) <= 31 * 9 + 23
Тогда "Дева"
Когда 31 * МЕСЯЦ([Менеджер.Физическое лицо.Дата рождения]) + ДЕНЬ([Менеджер.Физическое лицо.Дата рождения]) <= 31 * 10 + 23
Тогда "Весы"
Когда 31 * МЕСЯЦ([Менеджер.Физическое лицо.Дата рождения]) + ДЕНЬ([Менеджер.Физическое лицо.Дата рождения]) <= 31 * 11 + 22
Тогда "Скорпион"
Когда 31 * МЕСЯЦ([Менеджер.Физическое лицо.Дата рождения]) + ДЕНЬ([Менеджер.Физическое лицо.Дата рождения]) <= 31 * 12 + 22
Тогда "Стрелец"
Когда 31 * МЕСЯЦ([Менеджер.Физическое лицо.Дата рождения]) + ДЕНЬ([Менеджер.Физическое лицо.Дата рождения]) <= 31 * 12 + 31
Тогда "Козерог"
Иначе "Не указано"
Конец
В любом случае первое впечатление – много букв (причём, одинаковых). Работает, конечно, но как-то всё громоздко. Неэлегантно. Программист задумался и решил пойти другим путём. Он создал свойство Знак зодиака, общее у справочников ФизЛица и Пользователи и написал меленькую обработку, которая его заполняет. Функция собственно определения знака получилось примерно такая:
Функция ЗнакЗодиакаПоДате(Дата)
НазванияСтрока = "Козерог,Водолей,Рыбы,Овен,Телец,Близнецы,Рак,Лев,Дева,Весы,Скорпион,Стрелец,Козерог";
ДниМесяцаСтрока = "20, 19, 20, 20, 21, 21, 22, 21, 23, 23, 22, 22";
Названия = СтрРазделить(НазванияСтрока, ",");
ДниМесяца = СтрРазделить(ДниМесяцаСтрока, ",");
МесяцДаты = Месяц(Дата);
ДеньДаты = День(Дата);
ДеньГраницыЗнака = Число(ДниМесяца[МесяцДаты - 1]);
Если ДеньДаты <= ДеньГраницыЗнака Тогда
Название = Названия[МесяцДаты - 1];
Иначе
Название = Названия[МесяцДаты];
КонецЕсли;
Возврат Название;
КонецФункции
Букв теперь гораздо меньше. Это приятно. И никаких потенциальных проблем с доступом к персональным сведениям. А в отчёт – и кстати, кайф в том, что это может быть вообще любой типовой отчёт, в котором есть ФизЛицо или Пользователь – нужно всего лишь добавить новое поле. Благо, в СКД даже есть конструктор формул. И всё!
Плюсы от использования доп. реквизитов
Итак, что полезного мы видим.
1. Очевидный, самый главный плюс: резко упрощаются настройки. Это работает везде, где можно использовать доп. реквизиты: поля, структура, отборы...
2. В отчёт можно вывести данные, которые этим отчётом получить не просто сложно, а невозможно в принципе. Например, нужно добавить в отчёт по продажам (привет от нашего маркетолога) стаж работы менеджера. Если в ERP ещё как-то можно написать отдельный специальный отчёт, то, например, в УТ, где нет кадровых данных, совсем никак.
3. В некоторых случаях улучшается производительность. Если настройки достаточно сложные, если в них встречаются достаточно длинные цепочки ссылочных разыменований, если в них встречаются реквизиты составного типа... то в том запросе, который СКД фактически отправит в базу, получится очень много соединений. Нет нужды лишний раз повторять, что соединения плохо сказываются на производительности.
4. Один и тот же доп. реквизит можно использовать в разных отчётах с разными задачами. В типовых отчётах на СКД с точки зрения пользовательских настроек это такой же реквизит, как и все остальные. Если в типовом отчёте есть сам реквизит, то и его «вложенные» (дополнительные в том числе) реквизиты есть тоже.
Выбор: реквизиты или сведения
Сейчас, как и говорили в самом начале, немного о том, чем отличаются дополнительные реквизиты и сведения.
Что именно использовать, одной стороны, дело вкуса, с другой – вопрос принципиальный.
Перечислим некоторые факты, которые мы знаем про механизм(ы).
Реквизиты хранятся в самом объекте, а именно в табличной части ДополнительныеРеквизиты.
Сведения хранятся в специальном регистре ДополнительныеСведения.
Для того, чтобы записать реквизит, нужно записать сам объект.
При записи сведения нужно сделать запись в регистре, а объект записывать не нужно.
Дополнительные реквизиты отображаются непосредственно в форме объекта. В сложных формах (например, в формах большинства документов) на отдельной закладке, а в простых формах рядом с другими реквизитами.
Дополнительные сведения открываются в отдельном окне по специальной кнопке.
Обобщим сказанное.
То, что реквизиты хранятся в самом объекте, конечно, однозначно минус с точки зрения производительности при записи: сравните соответствующие обработчики в регистре и, например, в справочнике Номенклатура.
На реквизиты распространяются ограничения, которые есть у объекта. Например, дата запрета редактирования. Вообще, это может и плюсом и минусом. Зависит от ситуации. Если важно, чтобы реквизит оставался таким, каким он был при проведении документа, это плюс. Если реквизит согласно бизнес логике может изменяться задним числом, это минус. Однако здесь мы говорим о том сценарии, когда реквизиты заполняются независимо от документа. В конце дня, в конце месяца… но не при оформлении документа. В данном случае ограничения объекта будут мешать.
Реквизиты находятся на форме объекта. Если войти во вкус и насоздавать их штук, скажем, 10-20-30, только представьте, во что превратится форма объекта!
Таким образом, мы считаем, что конкретно для нашей задачи гораздо лучше использовать сведения.
Напоследок мнение. Просто личное мнение, ничего больше. Мы считаем, что не следует создавать новые реквизиты программно. Только вручную. Так процесс получается более осознанным. Иначе велик шанс наплодить – например, в случае ошибок в логике – ненужных реквизитов.
Обработка для обновления доп. реквизитов
Важное замечание.
Для того, чтобы предлагаемая схема работала, реквизиты нужно постоянно поддерживать в актуальном состоянии. Делать это вручную на практике нереально.
Прикладываем шаблон обработки, в которой реализована следующая упрощённая ситуация: у справочника ФизЛица есть дополнительное сведение Наименование. Обработка просто копирует туда наименование элемента. Опционально можно вставить перед наименованием первую букву этого наименования (это чтобы хоть как-то усложнить задачу!)
Нужно заменить это на вашу логику, а саму обработку добавить в список Внешние отчёты и обработки и настроить расписание.
Модуль обработки можно скопировать отсюда:
