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