Часто в практике разработки под 1С возникает задача доработки регламентированных печатных форм. Рассмотрим классическую ситуацию: имеется конфигурация 1С:Бухгалтерия предприятия 3.0, и поступило задание доработать макет Универсального передаточного документа (УПД). Заказчик хочет, чтобы рядом с именем ответственного лица (или в основании подписи) проставлялся номер и дата приказа или доверенности. Разберем по шагам, как можно реализовать данную задачу, не снимая конфигурацию с поддержки и не нарушая логику работы программы.
Прежде чем приступать к написанию кода, проанализируем ситуацию. УПД — это один из самых сложных документов в 1С с точки зрения формирования печатной формы. Программный код, собирающий данные для УПД, занимает тысячи строк, так как он должен учитывать множество налоговых нюансов, статус документа (счет-фактура или передаточный акт), прослеживаемость и маркировку.
Посмотрим на штатные возможности. Во многих случаях доработка кода вообще не требуется. В современных релизах конфигурации 1С:Бухгалтерия функционал подписантов постоянно развивается. В документах реализации по ссылке «Подписи» можно выбирать уполномоченных лиц. Если полномочия передаются сотруднику, в системе предусмотрено использование справочников доверенностей и полномочий.
Например, в печатной форме ТОРГ-12 штатно предусмотрен вывод основания подписи через запятую. Если корректно завести доверенность или приказ как основание права подписи для конкретного физического лица, программа сможет использовать эти данные автоматически. Однако, если стандартного вывода в УПД клиенту недостаточно (или формат вывода должен быть строго специфичным), переходим к программным методам.
Выясним причину, по которой многие разработчики боятся делать внешние печатные формы для УПД. Проблема заключается в огромном объеме кода. Если скопировать весь модуль формирования УПД во внешнюю обработку, при первом же обновлении конфигурации (особенно при изменении законодательства) ваша внешняя форма устареет и начнет выдавать ошибки.
Разберем более грамотный подход. Современный и надежный метод создания внешних печатных форм — это вызов типовой процедуры. Нам не нужно копировать логику. Мы можем программно попросить систему сформировать документ, а затем точечно изменить нужную ячейку.
ТабличныйДокумент.Примерный алгоритм действий в коде (схематично):
Функция Печать(МассивОбъектов, КоллекцияПечатныхФорм, ОбъектыПечати, ПараметрыВывода) Экспорт
// Вызываем типовой алгоритм формирования УПД
УчетНДСВызовСервера.ПечатьУниверсальныхПередаточныхДокументов(
МассивОбъектов,
КоллекцияПечатныхФорм,
ОбъектыПечати,
ПараметрыВывода
);
// Получаем сформированный табличный документ из коллекции
ТабличныйДокумент = Неопределено;
Для Каждого СтрокаФормы Из КоллекцияПечатныхФорм Цикл
Если СтрокаФормы.ИмяВРЕГ = "УПД" Тогда
ТабличныйДокумент = СтрокаФормы.ТабличныйДокумент;
Прервать;
КонецЕсли;
КонецЦикла;
Если ТабличныйДокумент <> Неопределено Тогда
// Программно ищем нужную область или ячейку и дописываем приказ
// Например, обходим ячейки или ищем текст ответственного
// ... (логика поиска) ...
// Ячейка.Текст = Ячейка.Текст + ", на основании Приказа №...";
КонецЕсли;
КонецФункции
Этот способ убережет вас от проблем при обновлениях 1С, так как основная сложная логика остается типовой.
Рассмотрим альтернативный вариант — использование механизма расширений. Многие разработчики делают ошибку: добавляют весь макет УПД в расширение и правят его там визуально. Заимствовать сам макет небезопасно, так как при обновлении конфигурации макет УПД часто меняется (меняются форматы, добавляются колонки для прослеживаемости и т.д.). Если ваш макет перекрывает типовой, пользователи лишатся новых обновлений печатной формы.
Вместо редактирования макета, проанализируем ситуацию с программной точки зрения. Мы можем перехватить процедуру заполнения параметров (с помощью аннотации &После). Когда типовой код собирает структуру параметров для вывода подвала, ваше расширение может вмешаться в этот процесс.
Мы находим в структуре параметров переменную, отвечающую за должность или ФИО ответственного лица (которое выводится параметром ФИОответственного), и программно приклеиваем к ней строку «на основании Приказа №...».
&После("ЗаполнитьПараметрыПодвалаУПД")
Процедура Расш1_ЗаполнитьПараметрыПодвалаУПД(ПараметрыПодвала, ДанныеДокумента)
Если ПараметрыПодвала.Свойство("ФИОответственного") Тогда
// Получаем данные о приказе из документа или регистра
СтрокаПриказа = ПолучитьПриказОтветственного(ДанныеДокумента.Ответственный);
Если ЗначениеЗаполнено(СтрокаПриказа) Тогда
ПараметрыПодвала.ФИОответственного = ПараметрыПодвала.ФИОответственного + " (" + СтрокаПриказа + ")";
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Такой подход максимально "чист" и не ломает типовые обновления макетов.
Обязательно рассмотрим еще один критически важный аспект. Очень важно понимать, что добавление реквизита исключительно в визуальный печатный макет УПД (через внешнюю форму или доработку табличного документа) никак не повлияет на формализованный электронный документ, отправляемый контрагенту.
Если организация обменивается документами через ЭДО, XML-файл формируется по строгим форматам ФНС. Чтобы контрагент увидел основание подписи в электронном документе, приказ должен быть указан в специализированных штатных полях области полномочий подписанта. Визуальная "дорисовка" текста в макете при передаче по ЭДО будет просто проигнорирована генератором XML.
Кроме того, в контексте приказов и делегирования права подписи стоит учитывать, что сейчас идет масштабный переход на Машинно-читаемые доверенности (МЧД). При подписании УПД электронно программа умеет штатно работать с МЧД. Номер и данные МЧД автоматически передаются в служебных полях документа как легитимное основание полномочий лица. В рамках ЭДО это полностью заменяет необходимость выводить бумажные реквизиты внутренних приказов в визуальный макет. Обязательно обсудите этот момент с заказчиком перед началом разработки.