«Автоматическое заполнение документа» звучит как одна операция: взять данные, вставить в шаблон, получить готовый файл. На тендерном пакете эта картинка почти сразу перестаёт совпадать с реальностью, потому что шаблона в привычном смысле часто просто нет — есть форма, которую собрал заказчик под свою закупку, со своей структурой ячеек, своими объединёнными столбцами и своими формулами, которые нельзя трогать. Заполнить такую форму — это не одна задача, а три отдельные, и каждая ломается в своём месте.
Коротко. Автозаполнение документа — это три разные задачи, а не одна. Сначала форму нужно найти: она часто напечатана как обычная таблица внутри PDF технического задания, без единого поля ввода. Затем — понять тип каждого поля: текст, число, дата и чекбокс требуют разной проверки и приходят из разных источников, а слот подписи — это позиция в форме, а не подпись, которую кто-то ставит. И только потом — вписать значение точечно, в файл заказчика, не разрушив его формулы и вёрстку. Большинство инструментов заполнения умеют только последний шаг, и то в тепличных условиях — на собственном шаблоне с заранее известными полями. Тендерный случай начинается там, где форма чужая.
Что на самом деле значит «заполнить документ автоматически»
Наивная картина «mail merge»: есть шаблон с плейсхолдерами вроде {{название компании}}, есть таблица с данными, инструмент подставляет одно в другое. Эта картина рабочая ровно до тех пор, пока шаблон делали вы сами и заранее знали, где в нём плейсхолдеры. В тендерном пакете форма приходит от заказчика — уже готовым файлом внутри пакета закупочной документации, без единого маркера, который бы отмечал «сюда пишем название компании», а «сюда» — ставку. Задача переворачивается: сначала нужно понять, где вообще в чужом документе находится форма и что именно в неё нужно вписать, и только потом — вписать.
Отдельно стоит закрыть один частый запрос сразу: если вы ищете автоматическое заполнение документов для 1С — счетов, накладных, УПД, — это не та задача и не та страница. У 1С свой мир форм и своя механика ввода данных, завязанная на собственную учётную систему, и мы туда сознательно не идём — здесь речь о заполнении форм тендерного пакета в .docx и .xlsx.
Запрос «какая программа лучше для автоматического заполнения» тоже стоит переформулировать, прежде чем отвечать на него: список из десяти названий инструментов не поможет, если каждый из них справляется только с тепличным случаем. Куда полезнее набор критериев, по которым стоит оценивать любой инструмент из этой категории: умеет ли он находить форму, которая физически не размечена как форма; различает ли он типы полей или относится к ним как к одинаковым строкам текста; правит ли он документ заказчика точечно или пересобирает его целиком, рискуя формулами и версткой.
Показательный пример того, где наивная картина ломается первой, — форма с объединёнными ячейками в шапке. Инструмент, рассчитанный только на плейсхолдеры в тексте, вообще не видит в такой странице ничего, что нужно заполнять: для него это просто текст и линии таблицы, а не набор полей ввода. Он справится с собственным шаблоном, где заранее знает, куда что вставлять, — и остановится на первой же чужой форме, потому что задача «найти, что заполнять» ему попросту не поставлена. Дальше — по порядку, по каждой из трёх задач, из которых на самом деле состоит заполнение.
Задача 1: найти форму, которой формально нет
Первая и самая незаметная проблема — не в том, что форму сложно заполнить, а в том, что её сложно вообще опознать как форму. Такая страница технического задания читается человеком с первого взгляда: вот клетки, вот подписи над ними, сюда явно нужно что-то вписать. Парсер, настроенный искать интерактивные поля ввода, этот сигнал не считывает вовсе — потому что у сетки нет ни одного поля AcroForm, ни какой-либо иной программной пометки «здесь заполняют».
Ровно на такую ситуацию однажды обратил внимание один из пользователей системы, разбирая реальное техническое задание: он увидел, что форма для заполнения в документе присутствует, а система на тот момент проходила мимо неё, не выделяя как что-то, требующее отдельного действия. Это была не жалоба на то, что распознавание не работает, а точное указание на границу — форма-таблица без разметки не читается как форма, если её этому специально не научить.
Функция extract_embedded_forms решает именно эту задачу: она выделяет из таблиц, напечатанных внутри страницы технического задания, подписанные поля вместе с их подписями — там, где у сетки есть заголовки строк или столбцов, по которым можно понять, какое значение куда должно встать. Если исходная форма — это скан или фотография, а не цифровой документ, ей сперва нужно распознавание: как оно устроено, разобрано в материале про распознавание документов.
Причина, по которой такие формы вообще массово встречаются без разметки, простая: заказчик собирал техническое задание не как интерактивный бланк, а как обычный документ Word, и таблица в нём — это просто таблица, как и любая другая на соседней странице. Различить в потоке из десятков страниц одну конкретную таблицу, которая на самом деле требует заполнения, среди множества таблиц, которые его не требуют, — задача, которую нельзя решить простым поиском «есть ли на странице сетка линий»: нужно смотреть на подписи полей и структуру, а не на факт наличия таблицы как таковой.
Задача 2: типизировать поля
Даже когда форма найдена и границы её полей понятны, поле — это не строка текста, а значение определённого типа, и с этим типом связаны разные требования. Текстовое поле принимает свободную формулировку. Числовое — только число, и лучше с проверкой на разумный диапазон, чем без неё. Дата должна прийти в формате, который заказчик укажет в самой форме, а не в произвольном — «01.09.2026» и «1 сентября 2026» для человека одно и то же, а для формы это два разных результата, и только один из них заказчик примет без вопросов. Чекбокс — это булево значение, а не текст «да» или «нет», вписанный в клетку. Слот подписи — это тоже поле формы: место, где должна стоять подпись, а не действие по её проставлению. Почему подписи сознательно остались за контуром системы — в «Что мы пробовали автоматизировать в документах — и отказались».
Разные типы полей заполняются из разных источников, и хорошая связка не спрашивает пользователя одно и то же на каждой новой закупке. Реквизиты компании — название, ИНН, юридический адрес, банковские данные — приходят из карточки компании, заведённой один раз. Опыт аналогичных контрактов, объёмы выполненных работ, примеры реализованных проектов — из портфолио кейсов, тоже заведённого заранее, а не собираемого заново под каждую форму. Функция fill_tz_form_file берёт типизированное значение — текст, число, дату или отметку чекбокса — именно из этих двух источников и подставляет его в конкретное поле формы, а не запрашивает его у человека при каждом заполнении.
Само определение типа не сводится к тому, что поле «выглядит как число» на глаз. Строка вроде «до 30 дней» текстово похожа на число, но по смыслу это условие срока, а не количество; ячейка с точкой вместо запятой в дробной части может быть числом, распознанным неверно из-за формата исходного файла. Различие между тем, что в поле должно стоять, и тем, что там написано на первый взгляд, — ровно та работа, ради которой типизация выделена в отдельный шаг, а не объединена молча с самой подстановкой значения.
Каждое значение проверяется по типу — текст, число, дата или чекбокс — прежде чем встать в поле формы.
Задача 3: вписать, ничего не сломав
Форма найдена, значения типизированы — остаётся последний шаг, и именно на нём чаще всего теряется доверие к инструменту заполнения. Файл, в который нужно вписать значения, — это документ заказчика: со своей вёрсткой, своими стилями, а в .xlsx — ещё и со своими формулами, которые ссылаются друг на друга и на итоговые ячейки. Инструмент, который вместо точечной правки пересобирает документ заново из полученного текста, рискует стереть именно то, что заказчик заложил в файл специально: формат ячейки, скрытую формулу пересчёта итога, объединение столбцов в шапке.
Заполнение fill_tz_form_file устроено как точечная правка, а не пересборка: run-surgical означает, что функция меняет конкретное значение в конкретной ячейке или прогоне текста, не трогая абзац или лист целиком; formula-guarded — что формулы Excel, если они есть в файле, распознаются и не перезаписываются как обычный текст; format-preserving — что шрифт, границы ячеек и структура документа заказчика после заполнения остаются такими же, как были до него. Наивный подход «прочитать содержимое, сгенерировать документ заново» этих трёх условий не даёт: сгенерированный заново файл может выглядеть похоже на исходный, но заказчик, открывший его на своей стороне, увидит другую вёрстку, слетевшие объединения ячеек или потерянную формулу итога — и такая заявка возвращается на доработку с формальным замечанием, даже если все данные в ней в итоге были верными.
Заказчик проверяет заявку в своём же файле — точечная правка сохраняет его вёрстку и формулы, пересборка рискует и тем, и другим.
Где автозаполнение честно останавливается
Первая граница касается подписи. Слот подписи в форме — это позиция, которую fill_tz_form_file умеет заполнить: место, где в форме ожидается подпись. Это не электронная подпись и не механизм подписания — система не ставит ЭП или ЭЦП и не принимает решения о том, кто и когда подписывает документ. Вопрос о подписании остаётся вне этого контура целиком.
Вторая граница — формы, которые система не увидела. Если extract_embedded_forms не смогла выделить поля из таблицы — структура слишком нестандартна, разметка неоднозначна — форма остаётся задачей человека: её нужно заполнить вручную, как если бы автоматизации не было вовсе. Это честнее, чем тихо пропустить форму или заполнить её частично, сделав вид, что заполнение завершено полностью.
Третья граница — форматы. Автозаполнение работает с .docx и .xlsx — файлами, где структура ячеек и полей читается и правится программно. PPTX, ODT, RTF и архивы вне этого контура: обещание «заполняем любой формат» в этой категории продуктов стоит воспринимать настороженно — скорее всего, вендор либо не сталкивался с реальным разнообразием форм в тендерных пакетах, либо не готов заранее назвать границу своего инструмента. Честнее сказать прямо, какие форматы поддерживаются, чем позволить пользователю обнаружить границу самому на важном документе.
Четвёртая граница — проверка перед подачей. Заполненную форму стоит открыть и просмотреть глазами, прежде чем прикладывать к заявке: автозаполнение снимает рутину переноса значений в нужные ячейки, но не снимает ответственность за то, что в итоговом файле всё расставлено верно, — эта проверка остаётся шагом человека, а не автоматической галочкой в конце процесса.
Все четыре границы связаны одной и той же логикой: там, где решение требует суждения или ответственности — подписание документа, интерпретация неоднозначной формы, финальная проверка перед отправкой, — граница называется вслух, а не маскируется общей формулировкой вроде «делаем всё за вас». Пользователю полезнее заранее знать, где заканчивается автоматизация, чем обнаружить это на реальной закупке в момент, когда формы уже нужно сдавать.
Место в маршруте подготовки
Заполнение форм стоит в конце маршрута подготовки пакета, и это не случайное место: материал о порядке сборки объясняет саму последовательность шагов и то, почему форма, заполненная раньше остальных, обычно переделывается заново после уточнений в техническом предложении. Три задачи из этого материала вступают в дело именно на этом, последнем шаге маршрута — не раньше. До заполнения форма должна быть сперва найдена внутри технического задания и её поля — сопоставлены с местом, куда должно встать конкретное значение; о том, как устроено это сопоставление и какие ошибки характерны для класса технологий, которые за ним стоят, — отдельный разбор нейросети для документов.
Мы в Кельве заполняем формы тендерного пакета этой связкой с 8 апреля 2026 года — как часть производственного контура, который перед этим уже нашёл форму внутри ТЗ и определил тип каждого поля. Роль системы здесь — типизировать значение, найти для него источник в карточке компании или портфолио и вписать его в файл заказчика, не тронув остального; закрепить итоговую заявку и проверить заполненный документ перед подачей — по-прежнему решение специалиста, который эту заявку подаёт. Три задачи из этого материала — найти, типизировать, вписать — работают у нас как единая цепочка, а не как три независимых инструмента, которые нужно запускать по отдельности и перепроверять результат вручную между шагами. Более широкий контекст того, из чего вообще состоит тендерный пакет и где он чаще всего разваливается, — в материале «Тендерная документация: из чего собирается пакет и где он разваливается».
