← На главную

При разработке и внедрении систем на платформе 1С:Предприятие часто возникает задача по передаче клиенту одного или нескольких объектов конфигурации, таких как отчеты, обработки или другие метаданные, без необходимости полной загрузки всей конфигурации. Это особенно актуально, когда размер полной конфигурации (файла .cf) достигает значительных объемов, а клиент имеет ограниченный или медленный доступ к интернету. Попытки просто «вырезать» нужный объект из большой конфигурации часто приводят к ошибкам из-за неучтенных зависимостей.

В этом руководстве мы подробно рассмотрим различные подходы к решению этой проблемы, проанализируем их преимущества и недостатки, а также предложим оптимальные методы, основанные на опыте разработчиков 1С.

Проблема выгрузки отдельного объекта конфигурации: почему это сложно?

Когда мы пытаемся выгрузить отдельный объект, например, отчет, в конфигурационный файл (.cf) и загрузить его в базу клиента, часто сталкиваемся с ошибками типа «значение не является значением объектного типа» или «метод объекта не обнаружен». Это происходит потому, что большинство объектов конфигурации не существуют в вакууме. Они имеют глубокие зависимости от других частей конфигурации:

1. Общие модули: Отчеты часто используют функции и процедуры из общих модулей, которые содержат общую логику для всей конфигурации.
2. Модули менеджера: Для отчетов, как и для других объектов, существуют модули менеджера, которые реализуют специфическую логику объекта, доступную из других частей системы.
3. Формы и макеты: Отчеты используют формы и макеты для представления данных.
4. Ссылки на метаданные: В запросах или в коде отчета могут быть прямые ссылки на другие объекты метаданных (справочники, документы, перечисления и т.д.).

При попытке выгрузить только сам отчет, мы упускаем из виду эти зависимости. В результате, при загрузке такого «урезанного» .cf файла в базу клиента, система не находит необходимых компонентов и выдает ошибки.

Метод 1: «Усечение» конфигурационного файла (.cf) с учетом зависимостей

Изначально авторы темы пытались использовать этот метод. Суть его заключается в следующем:

1. Создаем полную копию рабочей конфигурации в виде файла .cf (например, выгружаем конфигурацию поставщика или всю текущую конфигурацию).
2. Создаем совершенно новую, пустую информационную базу и загружаем в нее пустую конфигурацию.
3. Загружаем ранее созданный полный .cf файл в эту новую, пустую конфигурацию. Теперь у нас есть конфигурация, идентичная рабочей, но без данных.
4. Находим нужный нам объект конфигурации (например, отчет) и тщательно анализируем все его зависимости. Это критически важный шаг, где кроется большинство ошибок. Мы должны выявить:
   • Все общие модули, функции и процедуры которых вызываются из модуля отчета, модуля менеджера отчета или форм отчета.
   • Модули менеджера самого отчета (он должен быть).
   • Все формы отчета.
   • Макеты отчета (если есть).
   • Любые ссылки на другие объекты метаданных, используемые в схеме компоновки данных (СКД) отчета, запросах или коде (например, справочники, документы, перечисления). Если такой объект используется, необходимо оставить и его, иначе при запуске отчета он не сможет обратиться к отсутствующему метаданному.
5. Аккуратно удаляем из конфигурации все, кроме нужного отчета и всех его выявленных зависимостей. Это трудоемкий процесс, требующий внимательности. Для каждого удаляемого объекта система может выдать предупреждение о его использовании, что может помочь в выявлении зависимостей.
6. После удаления всего лишнего, выгружаем получившуюся минимальную конфигурацию в новый файл .cf.
7. Передаем этот небольшой .cf файл клиенту для загрузки.

Преимущества: Позволяет создать минимальный .cf файл. Недостатки: Высокая трудоемкость и риск пропустить какую-либо зависимость, что приведет к ошибкам при работе отчета у клиента. Если отчет глубоко интегрирован, такой файл может все равно оказаться достаточно большим, или же его создание станет слишком затратным по времени.

Именно этот метод изначально использовался автором темы. Ошибка «значение не является значением объектного типа» прямо указывает на то, что какая-то функция или переменная, являющаяся частью другого объекта (например, общего модуля или модуля менеджера другого отчета), не была найдена. Это происходит, например, когда в общем модуле есть вызов типа МенеджерОтчета = Отчеты[БухгалтерскиеОтчеты.ИмяОтчета(Форма)], и при выгрузке мы оставили только наш доработанный отчет, а соответствующий ему менеджер или общий модуль БухгалтерскиеОтчеты были удалены.

Метод 2: Использование внешнего отчета (.erf) и его ограничения

Часто в качестве решения предлагается переделать отчет во внешний (.erf) файл. Изначально это кажется идеальным решением, так как внешние отчеты предназначены для легкого распространения и использования без изменения конфигурации.

Как это работает:

Вы разрабатываете отчет как самостоятельный объект, который может быть открыт и выполнен в режиме 1С:Предприятия. Все необходимые процедуры и функции переносятся непосредственно в модуль объекта или модуль формы внешнего отчета.

Проблемы и ограничения для доработанных типовых отчетов:

Автор темы столкнулся с тем, что его отчет является доработанной копией типового отчета и имеет глубокие зависимости от общих модулей и модулей менеджера основной конфигурации. Попытка перенести всю логику из общих модулей и модуля менеджера в сам внешний отчет приводит к следующим проблемам:

1. Дублирование кода: Большая часть функционала типовой конфигурации будет продублирована в отчете, что делает его огромным и сложным для поддержки.
2. Потеря контекста: Внешний отчет работает в своем собственном контексте и напрямую не «видит» общих модулей или модулей менеджера, которые не были перенесены в его код. Если в коде отчета или его СКД есть ссылки на глобальные функции или переменные, определенные в общих модулях конфигурации, внешний отчет не сможет их найти.
3. Сложность рефакторинга: Переработка глубоко интегрированного типового отчета во внешний требует значительного объема работы по переносу и адаптации кода, что часто оказывается нецелесообразным. Например, если в общем модуле конфигурации функция ожидает объект типа ОтчетОбъект и обращается к его менеджеру через МенеджерОтчета = Отчеты[ИмяОтчета(Форма)], то внешний отчет не сможет корректно передать себя в эту функцию, или же придется править сам общий модуль, что «некошерно» (т.е. нарушает поддержку конфигурации).

Таким образом, для простых отчетов без глубоких зависимостей внешний .erf файл — отличное решение, но для сложных, интегрированных доработок он неприемлем.

Метод 3: Использование файлов обновления (.cfu)

Файлы .cfu (файл обновления конфигурации) предназначены для распространения изменений между двумя версиями конфигурации (старой и новой). Они содержат только те объекты и свойства, которые были изменены, добавлены или удалены. Файлы .cfu создаются автоматически при сравнении двух конфигураций.

Как это работает:

Предположим, у клиента есть конфигурация версии А. Мы берем ее, добавляем наш новый отчет (который является копией типового и доработан) и получаем конфигурацию версии Б. Затем мы создаем файл обновления, сравнивая конфигурацию версии А и версии Б. Этот файл .cfu будет содержать наш новый отчет и все изменения, которые он внес в конфигурацию (например, если он добавил новые общие модули или изменил существующие, чтобы его поддерживать).

Ограничения:

1. Назначение: .cfu предназначен для обновления существующей конфигурации, а не для добавления единичного объекта как независимой сущности.
2. Зависимость от базовой версии: Файл .cfu строго привязан к той версии конфигурации, для которой он был создан. Если у клиента другая версия, файл обновления может не примениться или привести к ошибкам.
3. Неудобство для нового объекта: Для простого добавления нового отчета использование .cfu может быть избыточным и не всегда интуитивным, так как он ориентирован на модификацию существующей структуры.

Хотя этот метод позволяет передать минимальный объем изменений, он больше подходит для регулярных обновлений конфигурации, а не для точечного добавления одного объекта.

Метод 4: Расширения конфигурации (.cfe) – современное и рекомендуемое решение

Начиная с версии платформы 8.3, фирма «1С» представила механизм расширений конфигурации. Это наиболее современный и рекомендуемый способ доработки функционала типовых конфигураций без снятия их с поддержки и без внесения прямых изменений в основную конфигурацию. Если конфигурация клиента использует управляемые формы, расширения — это то, что нам нужно.

Преимущества расширений:

1. Сохранение поддержки: Основная конфигурация остается на поддержке, что упрощает ее обновление без потери доработок.
2. Изоляция доработок: Все изменения и новые объекты (включая отчеты) хранятся в отдельном файле .cfe.
3. Простота распространения: Файл .cfe значительно меньше полного .cf файла и легко передается клиенту. Загрузка расширения происходит в режиме предприятия или через конфигуратор.
4. Доступ к основной конфигурации: Расширения имеют возможность «заимствовать» объекты основной конфигурации. Это означает, что новый отчет, созданный в расширении, может беспрепятственно использовать общие модули, справочники, документы и другие метаданные основной конфигурации без их дублирования.

Как создать отчет в расширении:

1. Откройте конфигуратор вашей рабочей базы.
2. Перейдите в меню «Конфигурация» -> «Расширения конфигурации».
3. Создайте новое расширение, задайте ему уникальное имя и версию.
4. Добавьте в расширение новый объект «Отчет». Сконфигурируйте его: добавьте схему компоновки данных (СКД), формы, макеты.
5. Если ваш отчет использует какие-либо общие модули или другие объекты из основной конфигурации, вам необходимо «заимствовать» их в расширение. Для этого в дереве объектов расширения (в ветке «Заимствованные объекты») добавьте нужные модули или ссылки на метаданные. При заимствовании объектов важно понимать, что вы не дублируете их, а указываете, что ваше расширение будет их использовать.
6. Напишите код отчета, используя заимствованные объекты и собственную логику.
7. Выгрузите расширение в файл .cfe. Этот файл и передайте клиенту.

При загрузке расширения в клиентской базе, отчет будет доступен и сможет корректно работать, обращаясь ко всем необходимым объектам основной конфигурации через механизм заимствования.

Метод 5: Выгрузка/Загрузка конфигурации в/из файлов (XML)

Этот метод представляет собой более гранулярный способ работы с конфигурацией, позволяющий выгружать ее в набор файлов различных форматов (XML, BSL для модулей и т.д.) и затем загружать обратно. Это бывает полезно для систем контроля версий или для частичного переноса доработок.

Как это работает:

1. В конфигураторе перейдите в меню «Конфигурация» -> «Выгрузить конфигурацию в файлы». Укажите каталог для выгрузки. Система создаст дерево каталогов, где каждый объект конфигурации будет представлен своими файлами (например, отдельный каталог для отчета, внутри него файлы для форм, макетов, XML-описание объекта и файл .bsl для модуля).
2. На своей стороне, после доработки отчета, вы также выгружаете конфигурацию в файлы.
3. Идентифицируете файлы, относящиеся к вашему доработанному отчету (например, каталог Reports/ИмяВашегоОтчета).
4. Копируете эти файлы (с заменой старых, если отчет уже существует) в соответствующее место в дереве файлов клиента. Или, если речь идет о добавлении нового отчета, просто добавляете новый каталог с его файлами в соответствующую ветку (например, в Reports/).
5. На стороне клиента (или удаленно) выполняете «Загрузить конфигурацию из файлов», указав корневой каталог.

Преимущества:

1. Точечный контроль: Позволяет очень точно управлять тем, какие части конфигурации вы переносите.
2. Совместимость с СКВ: Идеально подходит для использования с системами контроля версий (Git, SVN), так как изменения в файлах легко отслеживаются.
3. Частичная загрузка: Начиная с определенных версий платформы, поддерживается частичная загрузка из файлов XML через командную строку, что дает еще больше гибкости.

Недостатки: Требует понимания структуры файлов конфигурации, может быть сложным для ручного выполнения без автоматизации. Также, как и в случае с «усечением CF», вы все равно должны убедиться, что все необходимые зависимости отчета перенесены.

Резюме и рекомендации

Проблема выгрузки в CF одного объекта конфигурации, такого как отчет, и обеспечение его корректной работы у клиента, является достаточно частой и требует внимательного подхода к зависимостям.

1. Для современных конфигураций на управляемых формах (УФ), безусловно, наиболее предпочтительным и эффективным решением являются расширения конфигурации (.cfe). Они позволяют изолировать доработки, сохранять конфигурацию на поддержке и легко распространять изменения.
2. Если по каким-то причинам расширения не подходят (например, очень старая платформа, специфические требования), и объем данных нужно минимизировать, то метод «усечения» конфигурационного файла (.cf) может быть использован, но с обязательным и крайне тщательным учетом всех зависимостей отчета от других объектов конфигурации. Автор темы подтвердил, что этот метод (вероятно, с уточнением списка оставляемых зависимостей, как было упомянуто в сообщении со ссылкой на статью) оказался рабочим.
3. Метод выгрузки/загрузки конфигурации в файлы (XML) может быть полезен как альтернатива, особенно в средах разработки с системами контроля версий, но он также требует внимательного управления зависимостями.
4. Внешние отчеты (.erf) подходят только для простых отчетов без глубокой интеграции с типовой конфигурацией.
5. Файлы обновления (.cfu) предназначены для комплексных обновлений конфигурации, а не для точечного добавления одного объекта.

Каждый из этих методов имеет свою область применения. Выбор оптимального решения зависит от специфики вашей конфигурации, версии платформы, сложности отчета и требований к поддержке.