Как автоматизировать заполнение документов: шаблоны Word, таблицы и проверка полей

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

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

Когда подходит заполнение по шаблону

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

Отделите подстановку от составления документа. Система может взять customer_name из CRM и поместить его в поле «Заказчик». Она не должна самостоятельно выбирать условие договора, исправлять спорные реквизиты или придумывать отсутствующее значение.

Это также не извлечение сведений из входящих файлов. При заполнении система получает структурированные поля и переносит их в утверждённый шаблон. При извлечении сначала требуется распознать входящий документ и найти сведения. У этих процессов разные ошибки и критерии приёмки.

Как подготовить источник и карту полей

Сначала задайте контракт данных. В учебном contract-v1 запись описывает одну деловую редакцию документа и содержит ровно две фиксированные позиции. Уникальность пары (document_id, document_revision) не предполагается: её проверяют по всему неизменяемому снимку. Ноль, одна, три и более позиций останавливают миграцию. Для переменного количества строк нужен другой контракт с массивом позиций.

Ниже приведён синтетический пример, а не клиентский материал, готовый файл или результат внедрения Switch On AI.

Обязательные поля и источник данных

Во входной контракт входят исходные сведения. Миграция создаёт подготовленную запись contract-v2: преобразует дату, рассчитывает итоги строк и общий итог, находит расхождение с заявленной суммой и формирует условный блок. Значение source_declared_total поступает из CRM только для контрольного сравнения.

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

Формат реквизитов

ИНН, банковский счёт и другие идентификаторы храните как строки: числовой формат может отбросить ведущие нули. Проверка длины и символов не доказывает, что реквизиты существуют или принадлежат указанной компании.

Для даты сначала проверьте формат YYYY-MM-DD, затем календарную допустимость. В примере 2026-10-05 преобразуется в 05.10.2026, а 05/10/26 отклоняется как неоднозначное значение.

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

1. ROUND_HALF_UP(2.00 × 12500.00, 2) = 25000.00.
2. ROUND_HALF_UP(3.00 × 4000.00, 2) = 12000.00.
3. calculated_total = 25000.00 + 12000.00 = 37000.00.
4. delta = 37000.00 − 37000.00 = 0.00.

Миграция сохраняет source_schema_version = contract-v1, добавляет schema_version = contract-v2 и создаёт contract_date_text, итоги строк, calculated_total, delta и representative_block. При representative_required = false блок равен пустой строке.

Результат миграции — отдельная подготовленная таблица слияния. Исходную выгрузку CRM не изменяют.

Перед передачей снимку присваивают fingerprint. После проверки его содержимое не меняют. Синтетический шаблон может содержать поля {{contract_number}}, {{contract_date_text}}, {{customer_name}}, реквизиты, две фиксированные позиции, {{calculated_total}} и {{representative_block}}. Это обозначения контракта: фактический синтаксис зависит от выбранного инструмента.

Как выполнить слияние Excel и Word

Официальная документация Microsoft описывает Mail Merge для настольных Word for Microsoft 365, Word 2024, Word 2021, Word 2019 и Word 2016, включая указанные на странице редакции для macOS. Она требует подготовить Excel, подключить источник, выбрать получателей, вставить поля, просмотреть результат и завершить слияние. Описание ниже пересказывает эту документацию применительно к синтетическим данным; оно не является отчётом о запуске программы.

Перед работой внешний процесс формирует неизменяемый снимок подготовленной таблицы. Совпадения считают по всему снимку и точному составному ключу (document_id = "DOC-0042", document_revision = 1). Одно совпадение даёт matched_records = 1 и позволяет сформировать отдельный однострочный источник с selected_recipients = 1. Ноль совпадений даёт 0/0, два — 2/0. При результате, отличном от одного, создание документа не начинается.

Учебная последовательность по документации:

1. Подключить подготовленную таблицу Excel как источник.
2. Выбрать в списке получателей единственную строку DOC-0042/1.
3. Вставить поля слияния в утверждённый шаблон.
4. Открыть предварительный просмотр и пройти выбранные записи.
5. Завершить слияние и сохранить один кандидат на выпуск.

Перед выпуском сотрудник сверяет номер, реквизиты, дату 05.10.2026, две позиции, итоги 25000.00 и 12000.00, общий итог 37000.00, delta = 0.00, валюту RUB, отсутствие блока представителя и незаменённых маркеров. Для учебного контракта ожидаемое состояние после успешной проверки кандидата — released_documents = 1.

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

Отдельный механизм Microsoft — Word Online (Business) connector для Power Automate, Logic Apps, Power Apps и Copilot Studio. Действие Populate a Microsoft Word template работает с файлами в библиотеках, поддерживаемых Microsoft Graph: OneDrive for Business, SharePoint Online Sites и Office 365 Groups. Документация перечисляет поддерживаемые элементы управления содержимым, включая Plain Text и Repeating Section, требует уникальных названий элементов и указывает предел входного файла 10 МБ для соответствующих действий. Эти свойства относятся к облачному connector и не описывают настольный Mail Merge.

Как связать Google Sheets и Google Docs

Сопоставимый сценарий можно спроектировать через Google Sheets API v4, Google Drive API v3 и Google Docs API v1. Это учебная последовательность по официальной документации, а не отчёт о живом запуске:

1. Прочитать зафиксированный диапазон методом spreadsheets.values.get с подходящими правами.
2. Найти DOC-0042/1 и продолжить только при одном совпадении.
3. Проверить типы, обязательные поля, дату и суммы; построить contract-v2.
4. После успешной прикладной валидации создать request_key и generation_attempt_id.
5. Сохранить в журнале ключ, fingerprint, версии и планируемую операцию до внешнего вызова.
6. Создать копию шаблона методом files.copy и сохранить её external_object_id.
7. Передать замены маркеров одним вызовом documents.batchUpdate, проверить копию и только затем разрешить выпуск.

Метод spreadsheets.values.get возвращает значения выбранного диапазона, но не проверяет прикладной контракт. files.copy создаёт отдельный файл, а documents.batchUpdate изменяет уже созданный документ. Запросы одного batchUpdate сначала проверяются; недействительный запрос отклоняет весь пакет, а принятые обновления применяются вместе. Чтение Sheets, копирование Drive, изменение Docs и запись прикладного журнала остаются отдельными операциями, а не общей транзакцией.

Идемпотентность files.copy обеспечивает не Google Drive API, а проектируемый прикладной слой. generation_attempt_id обозначает попытку процесса, а отдельный operation_id — конкретный внешний вызов. Журнал по тому же request_key должен вернуть ранее сохранённое состояние и external_object_id, если копия уже появилась.

Если копирование прошло, а пакет замен отклонён, журнал сохраняет generated_documents = 1, external_object_id, output_check_status = rejected и released_documents = 0. Автоматически вызывать files.copy повторно нельзя.

Если исход files.copy неизвестен, журнал получает generated_documents = null, generation_outcome = unknown и release_status = manual_review. Новый ключ и новое копирование запрещены, пока сотрудник не установит судьбу первой операции.

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

Как добавить условия и сложные правила

Стандартного слияния достаточно при постоянной структуре и прямом соответствии колонок полям. Скрипт, Visual Basic for Applications (VBA) или отдельная интеграция нужны для переменного количества строк, составных условий, склонения, журнала и восстановления после сбоя.

Условные блоки

Контракт блока представителя задаёт три состояния:

• при representative_required = false блок пуст, итог остаётся 37000.00, а проверка ищет лишний пустой абзац;
• при true имя и основание обязательны, блок появляется один раз, суммы не меняются;
• при true и пустом обязательном поле система отказывает после чтения входа, но до создания request_key и любой внешней операции с документом.

В положительном синтетическом варианте заданы representative_name = Анны Сергеевны Орловой и representative_basis = доверенности № 7-У от 01.10.2026. Система вставляет блок один раз. Имя хранится в согласованной грамматической форме: система не склоняет его по догадке. Автоматическое склонение требует отдельного правила и самостоятельного набора тестов.

Несколько табличных строк

Учебный contract-v1 принимает ровно две полностью заполненные позиции. Миграция отклоняет ноль, одну, три и более позиций до создания request_key. Это ограничение примера, а не свойство Word или Google Docs.

Для переменного количества строк нужен отдельный контракт с массивом позиций. Его нельзя смешивать с колонками item_1_* и item_2_*. Реализация зависит от инструмента: это может быть повторяющаяся секция, скрипт, VBA или интеграция, которая меняет структуру документа.

Как проверить документ перед выпуском

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

Предварительный просмотр

Сотрудник сверяет число документов, идентификатор и редакцию, сторону, ИНН, банковский счёт, номер, дату, валюту, две строки, единицы, количество, цены и итоги. Затем ищет незаменённые маркеры, NULL, пустые обязательные подписи, сведения из прежнего документа, неожиданные переносы и лишний абзац после условного блока.

После изменения карты полей, миграции или шаблона повторяют затронутые проверки. Успешная базовая запись не заменяет отрицательные сценарии.

Ошибки исходных данных

В ошибочной синтетической записи заданы 0.50 × 20.01, 1.00 × 20.00 и заявленный итог 30.00:

1. Точное произведение 0.50 × 20.01 = 10.005.
2. ROUND_HALF_UP(10.005, 2) = 10.01.
3. ROUND_HALF_UP(1.00 × 20.00, 2) = 20.00.
4. calculated_total = 10.01 + 20.00 = 30.01.
5. delta = 30.01 − 30.00 = +0.01.

Запись получает validation_status = rejected. Для принятого входного события создаётся intake_id, но request_key = null; попытка выпуска не начинается; generated_documents = 0; released_documents = 0. Отказ происходит после чтения входа, но до любой внешней операции создания или изменения документа. Это правило учебного контракта, а не универсальное бухгалтерское требование.

Как управлять версиями и повторным созданием

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

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

Для каждой внешней операции журнал отдельно хранит operation_id, operation_type, external_object_id, время и результат. До первого внешнего вызова система должна успешно сохранить request_key, generation_attempt_id, ожидаемое имя, папку, fingerprint снимка и версии данных, шаблона и правил.

Повторный выпуск

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

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

При неизвестном исходе журнал сохраняет generation_outcome = unknown, generated_documents = null, released_documents = 0 и release_status = manual_review. Пока сотрудник не установит наличие или отсутствие результата, новый ключ и новый внешний вызов запрещены.

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

Когда такой контроль нужно связать с рабочей CRM, Switch On AI может помочь описать процесс, проверить доступные подключения и подготовить автоматизацию. Для заранее заданной последовательности обычно подходит обычная интеграция. ИИ-агент нужен только тогда, когда система должна выбирать следующее разрешённое действие по контексту. Подход к проектированию таких решений описан на странице разработки AI-агентов и автоматизаций.

Ошибки шаблонов и следующий шаг

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

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

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