Как организовать универсальное тестирование ВПФ с разными форматами макетов (MXL и Word)?

При разработке внешних печатных форм (ВПФ) часто возникает необходимость включать в одну обработку макеты разных типов: ТабличныйДокумент (MXL) и офисные документы (например, DOCX или ODT). Главная сложность заключается в том, что механизмы их формирования и вывода на печать принципиально различаются. Рассмотрим, как объединить эти подходы и сделать процесс тестирования удобным.

Анализ текущей архитектуры

Обычно разработчики сталкиваются с тем, что для каждого типа макета приходится создавать отдельные процедуры печати. В модуле формы прописывается вызов специфических функций: для офисных документов — использование УправлениеПечатьюКлиент.ИнициализироватьМакетОфисногоДокумента, а для табличных документов — стандартный метод ТабДок.Показать(). Чтобы не раздувать код и упростить отладку, нам необходимо прийти к унифицированному подходу.

Шаг 1: Унификация вызова процедур

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

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

Процедура Печать(ИдентификаторКоманды, ОбъектыНазначения) Экспорт
    // Получаем макет по идентификатору
    Макет = ПолучитьМакет(ИдентификаторКоманды);
    
    // Проверяем тип полученного объекта
    Если ТипЗнч(Макет) = Тип("ТабличныйДокумент") Тогда
        ПечатьТабличногоДокумента(Макет, ОбъектыНазначения);
    Иначе
        // Предполагаем, что это двоичные данные для Word
        ПечатьОфисногоДокумента(Макет, ИдентификаторКоманды, ОбъектыНазначения);
    КонецЕсли;
КонецПроцедуры

Шаг 2: Использование префиксов для идентификации

Если вы хотите избежать сложных проверок типов, воспользуйтесь методом присвоения имен макетам с использованием префиксов или суффиксов. Например, все макеты табличных документов называем МакетТаб_Название, а офисные — МакетВорд_Название.

Тогда логика выбора процедуры упрощается до анализа строки:

Если Лев(ИмяМакета, 8) = "МакетТаб_" Тогда
    // Вызов логики для табличных документов
ИначеЕсли Лев(ИмяМакета, 10) = "МакетВорд_" Тогда
    // Вызов логики для Word
КонецЕсли;

Такой подход позволит вам не плодить код для каждой новой кнопки, а просто добавить нужный макет в обработку и следовать выбранному правилу именования.

Шаг 3: Особенности вывода на печать в отладчике

Для того чтобы тестирование не превращалось в мучение с постоянной перерегистрацией внешней обработки, рекомендуем использовать следующие приемы:

• Создание формы-отладчика: Сделайте небольшую форму, где можно выбрать тип объекта (ссылку) и идентификатор макета из списка. Это избавит вас от необходимости постоянно вызывать основной функционал из документа.
• Работа с временными файлами: Для офисных документов всегда полезно сохранять результат во временный каталог перед открытием. Используйте ПолучитьИмяВременногоФайла("docx"), чтобы открывать актуальную версию документа без ошибок блокировки файла платформой.
• Единая структура данных: Старайтесь приводить данные для заполнения к единому формату Структура или Соответствие, независимо от того, какой макет вы заполняете. Это позволит использовать одну и ту же процедуру подготовки данных для обоих типов печатных форм.

Подводим итоги

Разделение логики на ПечатьТабличногоДокумента и ПечатьОфисногоДокумента — это правильный путь, но управление этим разделением должно быть централизованным. Проанализировав вашу задачу, мы пришли к выводу, что достаточно реализовать единую точку входа, которая будет «распределять» задачи по соответствующим процедурам. Это сделает ваш код чище, а процесс тестирования — предсказуемым и быстрым. Начните с создания единого интерфейса печати, и вы увидите, как работа с формами станет значительно проще.