Печатная форма в 1С: макет, табличный документ и СКД

Печатная форма в 1С:Предприятии редко ограничивается простым выводом реквизитов документа. Обычно требуется сохранить фирменное оформление, вывести табличную часть, сгруппировать данные, добавить подписи и корректно подготовить результат к печати или сохранению в PDF. Для таких задач удобно сочетать макет, табличный документ и схему компоновки данных.

Макет отвечает за визуальную структуру будущего документа, табличный документ — за формирование и вывод областей, а СКД помогает получить данные с нужными отборами, группировками и вычисляемыми полями. Разделение обязанностей делает разработку понятнее и упрощает дальнейшее сопровождение конфигурации.

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

Постановка задачи и выбор структуры формы

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

Для постоянных печатных документов обычно создают табличный макет с областями «Шапка», «Строка», «Подвал» и дополнительными блоками. Если документ содержит сложную аналитику, группировки или динамические отборы, источником данных может выступать схема компоновки данных. Это позволяет не зашивать всю логику выборки непосредственно в процедуру печати.

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

Подготовка макета табличного документа

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

При проектировании желательно учитывать реальную длину значений. Наименование номенклатуры, адрес контрагента или комментарий могут занимать несколько строк, поэтому для них предусматривают перенос текста и автоматическое увеличение высоты области. Жестко заданные размеры часто приводят к обрезанным данным при печати.

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

Формирование результата через схему компоновки

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

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

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

Связь данных с областями макета

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

Если используется СКД, следует отделять настройку компоновки от визуального вывода. Сначала формируется корректный набор данных, затем результат преобразуется в строки печатной формы. Такая архитектура упрощает отладку: разработчик может отдельно проверить запрос, настройки варианта отчета и оформление.

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

Разметка, страницы и служебные реквизиты

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

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

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

Проверка и сопровождение печатной формы

Тестирование проводят на коротком и длинном документе, с пустыми необязательными реквизитами, несколькими группами, большим количеством строк и разными вариантами отбора. Отдельно проверяют русские и числовые значения, округление, вывод дат, валюты и итогов.

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

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

Используйте именованные области, проверяйте результат СКД отдельно от оформления и обязательно тестируйте документ на реальных объемах данных. Такой порядок помогает создавать устойчивые печатные формы 1С, которые удобно развивать, сопровождать и адаптировать под требования пользователей.