При разработке под 1С часто возникает потребность сделать внешнюю печатную форму (ВПФ), которая будет корректно работать не в одной конкретной базе, а сразу в нескольких различных конфигурациях (например, одновременно в 1С:Бухгалтерии, 1С:ЗУП и 1С:ERP). Разные редакции, разные версии платформ и отличия в структуре метаданных сильно усложняют эту задачу. Давайте подробно разберем по шагам, как правильно спроектировать такую обработку, какие механизмы использовать и как обойти типичные ошибки.
Первое, что нам необходимо сделать для обеспечения универсальности — научить нашу печатную форму понимать, в какой именно базе она сейчас запущена. Проанализируем ситуацию: состав реквизитов документов в разных базах может отличаться, но базовые принципы остаются едиными. Чтобы разделить логику формирования макета, воспользуемся глобальным контекстом.
Рассмотрим пример кода, который позволит нам получить информацию о текущей конфигурации:
ИмяКонфигурации = Метаданные.Имя;
СинонимКонфигурации = Метаданные.Синоним;
ВерсияКонфигурации = Метаданные.Версия;
Если ИмяКонфигурации = "БухгалтерияПредприятия" Тогда
// Вызов функции сбора данных для БП
ИначеЕсли ИмяКонфигурации = "УправлениеТорговлей" Тогда
// Вызов функции сбора данных для УТ
КонецЕсли;
Используя этот подход, мы можем писать ветвления условий заполнения под различные конфигурации, обращаясь к специфичным таблицам только тогда, когда мы точно уверены, что находимся в нужной базе.
Большинство современных типовых конфигураций 1С построены на базе Библиотеки стандартных подсистем (БСП). Стандарт БСП для печатных форм меняется крайне редко, что играет нам на руку. Чтобы форма была доступна в интерфейсе баз, мы должны использовать экспортную функцию СведенияОВнешнейОбработке.
Для универсальной обработки лучше всего для каждой конфигурации добавлять свою отдельную команду в список команд. Рассмотрим, как это можно реализовать. Вы определяете метаданные, как мы разобрали выше, и в зависимости от конфигурации формируете нужные строки в таблице команд.
Далее в экспортной процедуре Печать() модуля обработки необходимо прочитать идентификатор вызванной команды и, соответственно, вызвать функцию формирования табличного документа для конкретной конфигурации. Важный нюанс: крайне желательно, чтобы версии БСП в базах были похожими. Если структура таблицы команд в старых (до 2.1) и новых (3.x) версиях БСП отличается, используйте безопасное добавление колонок.
Основная проблема универсальных форм — это обращение к реквизитам или регистрам, которых может не существовать в одной из баз. Если при сохранении модуля система обнаружит прямое обращение к несуществующему объекту (например, Объект.НекийРеквизит), мы получим ошибку синтаксического контроля.
Давайте выясним причину и способы решения. Если состав типов похож (например, везде есть справочники физических лиц, сотрудников или контрагентов), тексты запросов приходится писать с учетом структуры регистров. Чтобы обойти жесткий контроль платформы, используйте следующие приемы:
Выполнить() или Вычислить(). Платформа проверяет этот код только в момент его фактического выполнения, а не при компиляции всей обработки.Метаданные.ОбщиеМодули.Найти("ИмяМодуля").Часто разработчики сталкиваются с проблемой: при попытке получить адрес организации или контрагента через обращение через точку (например, СсылкаНаОбъект.Организация.КонтактнаяИнформация.Страна), система выдает ошибку «Поле объекта не обнаружено» или выводит техническое представление вместо адреса.
Проанализируем ситуацию. В современных конфигурациях контактная информация не хранится в простых реквизитах. Она находится в табличных частях (в старых базах) или в специальном формате JSON (поле ЗначенияПолей) в новых версиях. Обращаться к этим данным напрямую нельзя!
Посмотрим на правильное решение: используйте программный интерфейс БСП. Во всех конфигурациях на поддержке БСП есть общий модуль УправлениеКонтактнойИнформацией. Там содержатся все необходимые экспортные методы получения адресов, телефонов и email. Работают они одинаково надежно.
ВидКИ = Справочники.ВидыКонтактнойИнформации.ЮрАдресКонтрагента;
АдресСтрокой = УправлениеКонтактнойИнформацией.ПредставлениеКонтактнойИнформацииОбъекта(КонтрагентСсылка, ВидКИ);
Еще один частый вопрос — как сформировать буквенную запись итога документа (сумму прописью) так, чтобы это работало везде. Разберем варианты.
Вариант 1 (Типовые модули): Во многих конфигурациях есть модуль РаботаСКурсамиВалют с функциями вроде СформироватьСуммуПрописью. Но их наличие не гарантировано во всех базах.
Вариант 2 (Универсальный): Использовать встроенную функцию платформы 1С ЧислоПрописью. Этот метод будет работать абсолютно всегда, независимо от версии конфигурации. Вам нужно лишь передать само число и строку с параметрами валюты (рубли, копейки, их род и склонения).
Чтобы ВПФ была по-настоящему независимой, макет печатной формы (формат MXL) должен быть жестко встроен в саму внешнюю обработку. Не полагайтесь на общие макеты конфигурации, так как их структура может отличаться.
При проектировании макета давайте областям стандартные имена: Заголовок, Шапка, Строка, Подвал. Это значительно упростит адаптацию логики вывода, когда вы будете писать разные запросы для разных конфигураций, но выводить данные в один и тот же шаблон макета.
Также помните о структуре параметров. Стандартная процедура БСП принимает МассивОбъектов, КоллекцияПечатныхФорм, ОбъектыПечати и ПараметрыПечати. Используйте коллекцию ПараметрыПечати для гибкой передачи дополнительных настроек от пользователя к форме без переписывания основного кода печати.
Разработка универсальных форм требует постоянного тестирования. Отлаживать код каждый раз прикрепляя обработку в справочник «Дополнительные отчеты и обработки» — крайне долго.
Создайте внутри вашей внешней обработки обычную форму (форму отладки). Разместите на ней поле для выбора ссылки на документ (с типом ЛюбаяСсылка) и кнопку «Печать». По нажатию на кнопку просто вызывайте программно серверную процедуру модуля вашей обработки, передавая выбранную ссылку в виде массива. Это сэкономит вам десятки часов при проверке кода в разных конфигурациях.