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