При работе с расширениями конфигурации в 1С часто возникает ситуация, когда мы добавляем новые области печати в макет документа или отчета, но при попытке формирования печатной формы система выдает ошибку о том, что эти области не найдены. Парадоксально, что при этом изменения свойств уже существующих полей в том же макете, добавленном в расширение, успешно применяются. Давайте разберем, почему так происходит, и как мы можем эффективно решить эту проблему.
Мы выясним, что основная причина этой трудности кроется не столько в самом макете расширения, сколько в программном коде, который отвечает за формирование итоговой печатной формы. Давайте посмотрим, какие шаги необходимо предпринять, чтобы новые области печати, добавленные нами, корректно отображались.
Первым и наиболее критичным аспектом, который нам необходимо проанализировать, является программный код, ответственный за формирование печатной формы. Этот код обычно находится в модуле менеджера соответствующего документа, отчета или в общих модулях, посвященных управлению печатью. Мы часто предполагаем, что если макет в расширении содержит новые именованные области, то платформа автоматически их подхватит. Однако это не так.
Рассмотрим подробнее: когда мы изменяем существующие элементы макета (например, меняем текст в ячейке, шрифт, привязку к параметру), расширение "накладывает" эти изменения поверх базового макета, и они становятся видимыми, так как код базовой конфигурации продолжает ссылаться на ту же область, но теперь уже с примененными изменениями из расширения.
Но создание новой именованной области печати – это совершенно другая история. Для того чтобы новая область появилась в итоговом табличном документе, недостаточно просто определить ее в макете расширения. Мы должны явно указать в коде, что эта новая область должна быть выбрана и выведена. Если такого вызова нет, система, формирующая табличный документ, просто не будет знать о существовании этой новой области и, соответственно, не сможет ее найти, что приведет к ошибке.
Нам необходимо убедиться, что в коде, который генерирует табличный документ, добавлены явные вызовы для вывода новых областей. Это делается с помощью методов объекта ТабличныйДокумент, таких как Вывести или Присоединить. Например, если у нас есть новая область с именем "НоваяШапка", нам потребуется добавить в код что-то вроде:
Макет = ПолучитьМакет("ИмяНашегоМакета"); // Или УправлениеПечатью.МакетПечатнойФормы(ИмяНашегоМакета)
ОбластьНоваяШапка = Макет.ПолучитьОбласть("НоваяШапка");
ТабДок.Вывести(ОбластьНоваяШапка);
Мы должны найти соответствующий модуль и внести необходимые изменения, чтобы наш код "знал" о вновь добавленных областях и включал их в процесс формирования печатной формы. Если код ссылается только на старые, изначально существующие области базового макета, новые области, как бы мы их ни назвали и ни разместили в расширении, останутся невидимыми для программной логики.
Прежде чем углубляться в код, мы всегда должны убедиться, что макет был правильно заимствован в расширение. Тот факт, что изменения свойств существующих полей применяются, уже является хорошим индикатором того, что платформа использует версию макета из расширения. Это подтверждает, что наш макет из расширения действительно "активен". Однако это не исключает других проблем, связанных именно с новыми элементами.
Для проверки мы можем открыть расширение в конфигураторе, найти заимствованный макет и убедиться, что наши новые области печати, то есть именованные ячейки или диапазоны ячеек, с присвоенными им именами (например, "НоваяОбласть1", "ПодвалРасширения"), действительно присутствуют и корректно определены.
Если в нашей конфигурации используется Библиотека Стандартных Подсистем (БСП) для работы с печатными формами, то пользователи могут вносить изменения в макеты непосредственно в режиме предприятия. Эти пользовательские изменения, сохраняемые в регистре сведений "Макеты печатных форм", могут иметь приоритет над макетами, определенными в конфигурации или расширении. В такой ситуации макет, модифицированный пользователем, может "перекрывать" наш макет из расширения, и тогда новые области не будут видны.
Чтобы исключить эту возможность, нам следует проверить раздел "НСИ и администрирование" -> "Печатные формы, отчеты и обработки" -> "Макеты печатных форм". Если мы обнаружим там пользовательскую версию макета, который мы пытаемся модифицировать, то нам может потребоваться удалить ее. После удаления пользовательского макета система должна начать использовать либо базовый макет, либо макет из расширения (если он правильно заимствован и имеет приоритет).
В контексте БСП также может быть полезно обратить внимание на то, как происходит получение макета. Если в коде используется функция УправлениеПечатью.МакетПечатнойФормы(ИмяМакета), она может учитывать пользовательские макеты. В некоторых случаях, если мы хотим принудительно использовать макет из конфигурации или расширения, можно попробовать изменить вызов на ПолучитьМакет(ИмяМакета). Хотя это не всегда решает проблему с новыми областями, это может быть полезным шагом в диагностике, если проблема все еще сохраняется после проверки остальных пунктов.
При любых проблемах с применением изменений в расширениях, особенно касающихся макетов, первым делом рекомендуется выполнить очистку кэша 1С. Кэш может содержать устаревшие данные о макетах и других объектах конфигурации. Его очистка заставляет платформу заново загрузить актуальные версии всех объектов, включая изменения, внесенные нами через расширение. Мы можем очистить кэш, удалив каталоги кэша пользователя или запустив 1С с параметром /ClearCache.
%APPDATA%\1C\1CE\ или %LOCALAPPDATA%\1C\1CE\).Для точной локализации проблемы, особенно когда мы исчерпали все стандартные методы, рекомендуется использовать отладчик в режиме конфигуратора. Мы должны установить точку останова в начале процедуры или функции, которая отвечает за формирование нашей печатной формы. Пошаговое выполнение кода позволит нам увидеть:
МакетКомпоновкиДанных или МакетТабличногоДокумента) фактически используется в процессе формирования.Макет.Области или путем попытки Макет.ПолучитьОбласть("НазваниеНовойОбласти")).Используя отладчик, мы можем контролировать значения переменных, путь выполнения кода и состояние объектов, что является мощным инструментом для диагностики сложных проблем, связанных с макетами и расширениями.
Таким образом, проблема с невидимыми областями печати в расширении чаще всего сводится к тому, что наш программный код, ответственный за формирование печатной формы, не был обновлен для явного использования этих новых областей. В сочетании с проверкой пользовательских макетов и очисткой кэша, эти шаги позволят нам успешно интегрировать новые области печати в наши расширения. При необходимости обойти сложности доработки через расширение можно воспользоваться руководством по созданию внешней печатной формы на основе типовой.