Практика ЛДО · Интеграции

PDF из 1С по email через n8n: сценарий после согласования

Как построить отправку печатной формы из 1С по email: событие, подготовка PDF, доставка, подтверждение и повтор при ошибке.

Какой результат нужен бизнесу

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

В этом разборе используем ЛДО Интеграции и персональный n8n. Базовое согласование остаётся в 1С. Статья описывает порядок сборки по рецептам продукта; она не выдаёт демонстрационную схему за выполненную доставку конкретному клиенту.

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

Что подготовить до сборки workflow

  • Подключённые ЛДО Интеграции и работающий обмен с базой.
  • Тип документа и печатную форму, разрешённые администратором в настройках автоматизации 1С.
  • Учётные данные почтового сервиса в n8n и согласованный адрес отправителя.
  • Правило определения получателя. На пилоте — фиксированный тестовый адрес; в рабочем процессе — проверенный источник.
  • Ответственного за ошибки отправки и решение о повторе.

Первым шагом в узле «1С через LDO Relay» выполните «Получить возможности базы». В списках появятся разрешённые типы и формы. Если нужной формы нет, сначала уточните настройку в 1С: ввод произвольного имени формы в workflow не заменяет разрешение.

Для первого теста достаточно ручного запуска. Затем можно перейти к получению событий по расписанию и отбору нужного результата согласования. Не отправляйте PDF по любому изменению статуса без проверки смысла события.

Из каких шагов состоит отправка

  1. Получить событиеSchedule Trigger → Relay: «Получить события». Отобрать нужный тип и результат.
  2. Подготовить PDFПередать документ, его revision и разрешённую печатную форму.
  3. Отправить письмоSend Email использует бинарное свойство data как вложение.
  4. Подтвердить результатRelay: «Завершить» → «Подтвердить доставку PDF и событие».

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

Последний узел получает служебные ссылки на событие и файл. В рецепте это поля _ldo.event_id, _ldo.file_id и _ldo.sha256. При преобразовании данных промежуточными узлами сохраните их или настройте явное сопоставление. Без них успешную доставку нельзя корректно связать с исходным файлом.

Как выглядит ветвление в n8n

Демонстрационная схема n8n с запросом решения в Telegram и ветками согласования и доработки
Сохранённая демонстрационная схема n8n: решение в Telegram → две ветки обработки. Это иллюстрация построения workflow, а не скриншот работающей отправки PDF; подключения требуют настройки. Открыть в полном размере ↗

На сохранённом скриншоте другой учебный процесс: запрос решения в Telegram и две ветки ответа. Он показывает принцип работы редактора. Для PDF по email используются узлы из последовательности выше; готовый прикладной шаблон в каталоге продукта называется relay.pdf.email.

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

Что делать при ошибке и повторе

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

При временной ошибке отправки используйте ветку «Завершить → Вернуть событие на повтор». Задержку и условия повтора задаёт workflow. Ошибка адреса или неверные учётные данные требуют исправления настройки, а не бесконечного повторения.

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

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

Пять проверок перед рабочим запуском

  1. Верная форма. PDF открывается и относится к нужному документу и состоянию; имя файла и содержание понятны получателю.
  2. Верный адрес. Получатель определяется из согласованного источника, а не из случайного поля.
  3. Обычный успех. Письмо поступило в тестовый ящик, обработка подтверждена после отправки.
  4. Ошибка сервиса. Событие не подтверждено преждевременно и доступно для предусмотренного повтора.
  5. Неопределённый результат. Разобран случай «письмо ушло, подтверждение не прошло» и риск дублирования.

После пилота можно менять канал доставки. Для Telegram используется собственный бот организации; общие боты согласования ЛДО не предназначены для этой отправки PDF. Для S3, Nextcloud или другого назначения понадобятся соответствующий узел и отдельное подключение.

Архитектура обмена описана в статье «1С и n8n без публикации базы». Начинайте с проверенной доставки одного документа, затем расширяйте сценарий.

Основа разбора — рецепты и шаблоны ЛДО Интеграций. Подключения и результат доставки проверяются на вашей базе.