Проблема

Со временем в справочнике «Дополнительные отчеты и обработки» накапливаются десятки и сотни внешних отчетов, обработок и печатных форм. Что-то писали под разовую задачу, что-то давно забыто, что-то отключено, но не удалено.

Рано или поздно встает вопрос наведения порядка: что можно удалить, ничего не сломав? Отвечать «на ощупь» рискованно: удалишь обработку, а через неделю окажется, что она была нужна для закрытия месяца.

Обычные решения работают «в лоб»: ставят регистр-счетчик или расширение и начинают копить статистику запусков с момента установки. Чтобы получить достоверную картину, нужно ждать полгода-год.

Решение

Платформа и БСП штатно пишут в журнал регистрации событие подключения каждой дополнительной обработки. В записи есть всё, что нужно: ссылка на элемент справочника, пользователь, дата/время и приложение (тонкий клиент или фоновое задание).

То есть статистика использования уже накоплена — осталось её собрать и сопоставить со списком элементов справочника. Отчет делает именно это.

Реальный кейс. В базе ЗУП 3.1 в справочнике было более 130 внешних отчетов и обработок. Первый же запуск отчета показал, что за анализируемый период реально использовалось около 20 из них («Приказ на отпуск», «Табель учета рабочего времени (Т-12)», «Реестр в банк» и др.), а остальные — кандидаты на удаление. Без периода ожидания и без правок конфигурации.

Что показывает отчет

По каждому элементу справочника «Дополнительные отчеты и обработки»:

Из справочника:

• Наименование, группа (папка), вид (отчет / обработка / печатная форма / заполнение объекта и т. д.);
• Статус публикации (опубликовано / для тестирования / не опубликовано);
• Ответственный, пометка удаления, имя файла, версия, комментарий.

Из журнала регистрации (за выбранный период):

• Количество подключений;
• Дата последнего использования;
• Количество уникальных пользователей;
• Признак фоновых подключений (информационный: обработка выполнялась асинхронно).

Вычисляемые:

• Дней без использования;
• Статус-«светофор».

  Статус	Что означает
  Помечена на удаление	Уже помечена — готова к удалению
  Отключена (не опубликована)	Не видна пользователям в интерфейсе
  Не используется	Ни одного подключения за период
  Давно не используется	Подключения были, но давно (порог настраивается, по умолчанию 180 дней)
  Используется	Активно подключается

Аналитика в СКД: группировка по статусу с итогами (сразу видно «Не используется (N)»), цветовая подсветка, сортировка по давности неиспользования, отборы по виду, группе, ответственному, публикации. Двойной клик — переход в карточку элемента.

Изображение 1: общий вид отчета — блоки по статусам со «светофором» и итогами.

Изображение 2: форма настроек с периодом и порогом давности.

Изображение 3: фрагмент блока «Не используется» / «Давно не используется» с примерами забытых обработок.

Изображение 4: фрагмент блока «Используется» — счетчики, последний запуск, пользователи.

Преимущества перед аналогами

Как это устроено (для разработчиков)

Источников всего два, оба штатные:

1. Справочник «ДополнительныеОтчетыИОбработки» — один запрос. ХранилищеОбработки сознательно не выбираем, чтобы не тянуть мегабайты двоичных данных.
2. Журнал регистрации — через ВыгрузитьЖурналРегистрации() с отбором.

Три технических момента, на которых стоит остановиться.

а) Выгрузка сразу в ТаблицуЗначений, без парсинга XML. Платформа возвращает в колонке «Данные» готовую СправочникСсылку, поэтому связка «событие → элемент справочника» делается напрямую.

ОтборЖР = Новый Структура;
ОтборЖР.Вставить("ДатаНачала",    ДатаНачала);
ОтборЖР.Вставить("ДатаОкончания", ДатаОкончания);
ОтборЖР.Вставить("Метаданные",    Метаданные.Справочники.ДополнительныеОтчетыИОбработки);
ОтборЖР.Вставить("Событие",       "Дополнительные отчеты и обработки");
ВыгрузитьЖурналРегистрации(ТЗ_ЖР, ОтборЖР,
    "Дата, ИмяПользователя, Данные, ПредставлениеДанных, ПредставлениеПриложения");

б) Двойной отбор «Метаданные + Событие». По метаданным справочника в журнал попадают и события «Данные. Изменение» — это редактирование карточки, а не использование. Фильтр по событию отсекает такие ложные срабатывания. Оба условия работают на уровне индексов ЖР, что важно на больших объемах журнала.

в) Подача данных в СКД через внешние наборы. Плоская таблица «справочник + статистика» формируется программно и передается в компоновку как внешний набор данных (КомпоновщикМакетаКомпоновкиДанных + ПроцессорКомпоновкиДанных.Инициализировать(Макет, ВнешниеНаборы, …)), без временных таблиц и ЛЕВЫХ СОЕДИНЕНИЙ в запросе.

Совместимость и требования

Конфигурации: любые конфигурации на управляемых формах, использующие БСП и справочник «ДополнительныеОтчетыИОбработки»: ЗУП 3.1, УТ 11, КА 2, ERP 2.x, БП 3.0, УНФ, ДО 2.x и т. д. Протестировано на ЗУП 3.1; совместимость с другими конфигурациями на УФ + БСП предполагается, но требует проверки на конкретной базе.

Требования:

• Платформа 8.3 (поддержка ВыгрузитьЖурналРегистрации с отборами);
• У пользователя — право чтения журнала регистрации (фактически роль Администратора или Полные права);
• В настройках ЖР должна быть включена регистрация событий подключения внешних обработок (в типовых конфигурациях включена по умолчанию).

Не поддерживается: конфигурации на обычных формах со справочником «Внешние обработки» (УПП, УТ 10.3) — там иная модель хранения и другие события журнала.

Установка и использование

1. Поместите файл .epf в базу как дополнительную обработку/отчет (или откройте напрямую).
2. Укажите период анализа и при необходимости порог «давности» (по умолчанию 180 дней).
3. Сформируйте отчет. Группы со «светофором» сразу покажут, сколько элементов не используется.
4. Для принятия решения используйте отборы и двойной клик для перехода в карточку.

Изображение 5: форма отчета с параметрами.

Ограничения (важно)

1. Глубина ретроспективы ограничена сроком хранения журнала регистрации в конкретной базе. Если журнал чистится раз в месяц — историю за год получить нельзя.
2. Подключение ≠ каждое нажатие. Событие фиксирует загрузку внешнего модуля. Из-за кеширования модуля счетчик — индикатор активности, а не точное число запусков. Для задачи «используется / не используется» этого достаточно.
3. Фоновые задания — это те же пользователи. Асинхронное выполнение длительных методов обработки в ЖР выглядит как «Фоновое задание», но инициировано тем же пользователем. Поэтому признак фоновых подключений — информационный и на статус не влияет.
4. Если регистрация событий отключена, отчет покажет все как «не используется». Проверьте настройку журнала перед анализом.

Связанные публикации

 Экспорт/импорт дополнительных отчетов и обработок — обработка для массовой выгрузки и загрузки элементов справочника «ДополнительныеОтчетыИОбработки». Удобная связка: этот отчет находит «мертвый груз», а обработка позволяет массово выгрузить или загрузить нужный парк файлов.