При настройке автоматизации в 1С:Управление нашей фирмой (УНФ) пользователи часто сталкиваются с неприятной ситуацией: шаблон электронного письма настроен корректно, выбраны параметры заказа и счета, но при получении письма клиентом поля, относящиеся к счету, оказываются пустыми. В то же время данные самого заказа (номер, дата) подставляются без проблем. Разберем детально, почему так происходит и какие способы решения существуют для этой задачи.
Для начала выясним причину, по которой система «игнорирует» данные счета. В 1С:УНФ механизмы формирования писем по шаблону работают в определенном контексте. Когда мы создаем шаблон для документа Заказ покупателя, основным источником данных выступает именно этот документ. Счет на оплату является подчиненным документом. Связь между заказом и счетом — это связь «один ко многим»: на один заказ может быть выписано несколько счетов (на разные суммы, разные даты или разные этапы оплаты).
Стандартный парсер шаблонов писем не обладает встроенной логикой, которая позволила бы ему самостоятельно решить, какой именно из трех-пяти выставленных счетов нужно подставить в письмо. В результате, не найдя однозначного соответствия «один заказ — один счет», система оставляет поля параметров пустыми. Рассмотрим подробнее, как мы можем обойти это ограничение штатным и нештатным функционалом.
Самый простой и эффективный способ предоставить клиенту информацию о счете — это не вписывать его номер текстом, а прикреплять полноценный документ в формате PDF. Посмотрим, как настроить этот процесс в разделе CRM.
Счет на оплату.При таком подходе система в момент срабатывания триггера (смены статуса) проанализирует связанные документы. Если найден проведенный Счет на оплату, программа автоматически сформирует его печатную форму и добавит вложения в письмо. Это решает проблему информативности: клиент получит не просто номер счета текстом, а готовый к оплате документ.
Если нам критически важно видеть номер счета именно в теле письма, проанализируем ситуацию с использованием дополнительных реквизитов. Поскольку данные самого заказа подставляются всегда, мы можем «приземлить» данные счета непосредственно в заказ.
Рассмотрим пошагово этот алгоритм:
Заказ покупателя добавим новый дополнительный реквизит НомерСчетаДляПисьма (тип «Строка»).Чтобы данные в этот реквизит попадали автоматически, можно использовать механизм расширений или простую подписку на событие записи документа Счет на оплату. Разберем пример логики кода, который мог бы заполнять это поле:
Процедура ПриЗаписиСчета(Источник, Отказ)
Если Источник.ДокументОснование.Тип() = Тип("ДокументСсылка.ЗаказПокупателя") Тогда
ЗаказОбъект = Источник.ДокументОснование.ПолучитьОбъект();
ЗаказОбъект.ДополнительныеРеквизиты.Очистить(); // логика поиска конкретного доп. реквизита
// Заполняем реквизит НомерСчетаДляПисьма номером текущего счета
// ... (код поиска и заполнения значения реквизита)
ЗаказОбъект.Записать();
КонецЕсли;
КонецПроцедуры
Таким образом, информация о счете становится частью данных самого заказа, и система без труда подставит её в письмо.
Для продвинутых пользователей и администраторов существует возможность настройки шаблонов через механизм Системы компоновки данных. Выясним, как это работает. В современных версиях УНФ (начиная с 1.6.15 и выше) конструктор шаблонов позволяет редактировать схему компоновки, которая собирает данные для письма.
В настройках шаблона мы можем добавить новый вычисляемый параметр. Например, мы хотим выбрать самый последний созданный счет по заказу. Для этого в схеме компоновки данных создается запрос к таблице Документ.СчетНаОплату с фильтром по ДокументОснование = &Заказ и сортировкой по дате (убывание). Выбрав «Первый 1», мы получим конкретную ссылку, из которой параметры (номер, дата, сумма) будут подтягиваться в тело письма без сбоев.
Часто пользователи замечают, что не подставляются не только данные счета, но и данные организации (наименование, телефон). Рассмотрим, как это исправить:
Заказ покупателя поле Организация заполнено. Если в базе ведется учет по нескольким фирмам, и поле пустое (или не выбрано по умолчанию), система не сможет определить, чьи реквизиты подставлять.Нельзя забывать и про технический аспект прав доступа. Выясним, как права влияют на «пустые поля». Автоматическая отправка писем обычно выполняется под учетной записью регламентного задания. Если у пользователя, под которым запускается служба регламентных заданий (или у системного администратора в базе), ограничены права на просмотр документа Счет на оплату (например, через RLS — ограничение на уровне записей), то при формировании письма система просто «не увидит» данные счета и оставит поля пустыми.
Рекомендация: Проверьте профиль пользователя, под которым работает серверное регламентное задание. У него должны быть полные права на чтение всех типов документов, участвующих в цепочке продаж.
Подводя итог нашему анализу, отметим, что проблема «пустых полей» — это не ошибка программы, а следствие неопределенности данных. Мы рекомендуем использовать Способ №1 (прикрепление PDF) как наиболее надежный и профессиональный с точки зрения клиентского сервиса. Если же текстовая информация в теле письма критична — используйте Способ №2 (дополнительные реквизиты), который гарантирует 100% заполнение данных вне зависимости от сложности структуры подчиненных документов.