Договоры по шаблонам в таблице: свой генератор из одной заполненной строки

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

А началось всё с обычной рутины с договорами.

У нас договорные данные устроены по-разному. Пациент может оплачивать услугу сам. Иногда плательщиком становится организация или представитель. Поэтому одной колонки «клиент» мне постоянно не хватало.

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

Сначала я попросила помощника сделать «программу для договоров». Получился слишком общий план с лишними экранами и функциями. Я остановила работу и описала сам порядок оформления: какие данные вводятся, кто платит, какая услуга оказывается и кто подписывает документ.

После этого схема стала понятной. Таблица хранит данные. Google Docs хранит форму договора. Apps Script связывает их и записывает ссылку обратно.

Мне не пришлось разбираться в коде. Я только проверила глазами несколько вариантов и оставила в форме те поля, которые действительно нужны в работе.

Как изменилась рутина, когда договор собирается из строки?

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

Строка выглядит примерно так:

patient | payer | service | signer | contract_date | document_url | status

В поле patient я указываю пациента. В payer - того, кто оплачивает услугу. Если эти люди совпадают, это всё равно остаются два разных поля. Так правило видно прямо в таблице, а не спрятано в моей голове.

В service попадает перечень услуг. В signer - человек, чья подпись нужна в договоре. Дата и служебные поля находятся рядом, поэтому готовый документ можно быстро найти по строке.

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

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

Почему свою таблицу нельзя сравнивать с готовым сервисом?

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

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

Важно не добавлять поля просто на всякий случай. Каждое новое поле становится ещё одной точкой для ошибки.

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

Свою таблицу я выбираю не потому, что она умеет всё. Она закрывает конкретную повторяемую работу: принять данные, проверить обязательные поля, собрать документ и вернуть ссылку.

Из чего состоит договор из одной строки?

Цепочка выглядит так:

строка таблицы -> шаблон Google Docs -> готовый договор -> ссылка в таблице

В таблице первая строка хранит заголовки. Следующая строка хранит данные конкретного договора. Скрипт читает диапазон как набор строк и колонок, а затем сопоставляет заголовок с нужным полем.

Для клиники подойдут такие поля:

patient
payer
service
signer
contract_date
document_url
status

В Google Docs я ставлю переменные с теми же понятными названиями:

Пациент: {patient}
Плательщик: {payer}
Услуга: {service}
Подписант: {signer}
Дата договора: {contract_date}

Названия должны быть согласованы заранее. Google Таблицы сами не понимают, что patient означает «пациент», а payer - «плательщик». Это правило задаётся в логике сборки.

Apps Script получает значения строки, открывает копию шаблона и заменяет каждую переменную. В документации Google этот механизм описан так:

После замены скрипт сохраняет готовый документ на Google Диске. Его ссылка попадает в document_url, а в status записывается результат обработки.

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

Что поставить перед сборкой и какие доступы подготовить?

На компьютер ставятся две вещи: редактор VS Code и помощник Claude Code. Помощник встраивается в редактор и работает прямо внутри него. Сам код я не пишу и не копирую. Я описываю задачу словами, а помощник создаёт и меняет файлы.

Установка сводится к трём действиям: скачать программы, запустить установщик и войти в аккаунт. Делается это один раз. Потом те же инструменты пригодятся для другой автоматизации, изменится только описание задачи.

Для самой схемы подготовь:

1. Google-аккаунт.
2. Google Таблицу, где есть права редактора.
3. Пустой лист для данных договоров.
4. Шаблон Google Docs с переменными.
5. Проект Apps Script, привязанный к таблице или созданный отдельно.
6. Разрешения на чтение таблицы, создание документов и работу с Google Диском.

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

Платная подписка помощника является постоянной статьёй расходов. Точную цену подписки и готового сервиса я здесь не называю: она зависит от условий и тарифов. Стоимость Google Таблиц и других компонентов тоже нельзя свести к слову «бесплатно»: лимиты Apps Script и цена аккаунта зависят от условий использования.

Как собрать договор из одной строки?

1. Опиши правило договора.

   Открой папку проекта в VS Code и сначала попроси помощника разобраться в задаче. Не проси сразу «сделать программу». Расскажи, кто такой пациент, кто такой плательщик и кто подписывает документ.

   Разобрать задачу клиникиСкопировать промпт

   У меня медицинская клиника. Я оформляю договоры на платные услуги. Пациент может оплачивать услугу сам, а может прийти по договору с организацией или через представителя. Мне нужна связка Google Таблица + Google Docs + Apps Script: я заполняю одну строку, а система проверяет обязательные поля и собирает договор по шаблону. Отдельно храни пациента, плательщика, услугу и подписанта. Пока не пиши код. Разбери задачу простым языком, перечисли данные, которые нужны в строке, и задай вопросы, если чего-то не хватает. Не добавляй медицинские диагнозы и данные конкретных пациентов.

   Помощник должен выдать список полей и порядок сборки. Проверь, что пациент и плательщик не объединены в одно поле. Если в плане появились лишние экраны или медицинские данные, попроси убрать их.

2. Создай структуру таблицы.

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

   Создать таблицу полей договораСкопировать промпт

   Создай структуру Google Таблицы для договоров на платные медицинские услуги. Первая строка должна содержать заголовки: patient, payer, service, signer, contract_date, document_url, status. Добавь отдельное поле payment_basis для основания оплаты. Пациент и плательщик должны быть разными полями даже в случае, когда это один человек. Подготовь одну тестовую строку с вымышленными данными. Не добавляй диагнозы, медицинскую историю и другие сведения, которые не нужны для договора. Объясни простым языком, какое значение хранится в каждом столбце.

   В ответе появится структура таблицы и описание полей. Проверь, что document_url и status остаются пустыми до запуска, а обязательные поля перечислены отдельно.

3. Разметь шаблон документа.

   Открой Google Docs и вставь переменные в те места, где должны появиться данные из таблицы. Затем попроси помощника связать смысл полей.

   Связать таблицу с шаблоном Google DocsСкопировать промпт

   Подготовь логику связи Google Таблицы и шаблона Google Docs. Заголовки таблицы: patient, payer, service, signer, contract_date, payment_basis, document_url, status. В шаблоне используются переменные {patient}, {payer}, {service}, {signer}, {contract_date}, {payment_basis}. Сопоставь каждую переменную с одноимённым заголовком таблицы. Не используй номера столбцов, ищи значения по заголовкам. Перед изменением перечисли файлы и настройки, которые собираешься менять.

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

4. Добавь проверку полей.

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

   Проверить обязательные поля перед созданиемСкопировать промпт

   Добавь перед генерацией договора проверку обязательных полей. Обязательными считаются patient, payer, service, signer, contract_date и payment_basis. Если хотя бы одно поле пустое, не создавай документ, не записывай ссылку и поставь в status понятное сообщение об ошибке. Покажи, какое поле не заполнено. Проверяй значения по заголовкам столбцов, а не по их номерам. После успешной проверки передавай данные в шаблон Google Docs.

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

5. Создай копию документа.

   Работай только с копией шаблона. Исходный Google Docs должен оставаться чистым, иначе после первого запуска в нём могут замениться переменные.

   Создать договор из проверенной строкиСкопировать промпт

   Добавь обработку одной строки Google Таблицы. После успешной проверки скопируй шаблон Google Docs, замени в копии переменные {patient}, {payer}, {service}, {signer}, {contract_date} и {payment_basis} значениями из этой строки. Исходный шаблон не изменяй. Назови копию понятным именем с датой договора и пациентом, если это допустимо правилами хранения данных. После сохранения запиши ссылку на копию в document_url и установи status = created. Если создание не удалось, не ставь статус created, а запиши понятную ошибку.

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

6. Запиши ссылку и статус.

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

   Добавить статусы и защиту от повтораСкопировать промпт

   Добавь в обработку статусы строки: NEW, validation_error, creating, created и error. Перед созданием проверь status. Если в строке уже есть document_url и status = created, второй документ не создавай. Сначала поставь creating, после успешного сохранения документа запиши ссылку в document_url и поставь created. При ошибке запиши status = error и текст ошибки в отдельный столбец error_message. Не удаляй исходную строку.

   Проверь два сценария. Сначала обработай тестовую строку. Затем запусти обработку ещё раз. Второй запуск не должен создавать новую копию.

7. Настрой запуск новых строк.

   Для начала достаточно обработки по расписанию. Она ищет строки со статусом NEW и не зависит от того, как именно появилась запись.

   Обработать новые строки по расписаниюСкопировать промпт

   Настрой обработку новых строк Google Таблицы по расписанию. При каждом запуске находи строки со статусом NEW, проверяй обязательные поля, создавай договор только для корректных строк и записывай ссылку и статус обратно. Не создавай новый триггер при каждом запуске. Не обрабатывай строки со статусами created, creating, validation_error или error без отдельной команды. Предусмотри журнал с номером строки, временем запуска, статусом и текстом ошибки.

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

8. Проведи контрольную проверку.

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

   Проверить готовый договор глазамиСкопировать промпт

   Создай контрольный сценарий для договора из строки Google Таблицы. Проверь отдельно: пациент подставлен в поле пациента, плательщик подставлен в поле плательщика, услуга не пустая, подписант указан правильно, дата не сместилась на соседний день, основание оплаты присутствует, в документе не осталось переменных вида {patient} или {payer}, ссылка открывает нужную копию, а повторный запуск не создаёт второй документ. Результат проверки запиши простым списком без технических терминов.

   Ответом станет список проверок. Выполни их на тестовой строке, а затем повтори на строке с другим плательщиком. Так сразу видно, не смешиваются ли участники договора.

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

Что появится в папке после успешной сборки?

В таблице останется строка с исходными данными и результатом:

patient | payer | service | signer | contract_date | document_url | status

В Google Диске появится копия шаблона. Она отличается от исходного документа тем, что переменные заменены значениями строки.

Если в схеме включён экспорт, рядом может появиться PDF или DOCX. Это дополнительный формат, а не обязательная часть базовой сборки. Для начала достаточно Google Docs и ссылки в таблице.

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

Первое, что я смотрю в готовом договоре, - не осталось ли там {patient}, {payer} или другой переменной. Если осталась хотя бы одна, документ нельзя отправлять без ручной проверки.

Что делать, если договор создаётся дважды или дата съезжает?

1. Убери повторное создание. Если одна строка даёт несколько документов, отправь помощнику:

Договор создаётся дважды. Добавь блокировку от параллельных запусков и проверку статуса. Не создавай повторный документ для уже обработанной строки: если document_url заполнен и status = created, пропускай строку. Не создавай новые триггеры во время обработки. Объясни, какие файлы изменил и как проверить исправление на одной тестовой строке.

Проверь, что у проекта не создано несколько одинаковых триггеров. В строке должны быть отдельные состояния creating и created.

2. Исправь дату. Если дата договора становится предыдущим или следующим днём, напиши:

Дата договора съезжает на соседний день. Проверь часовой пояс Google Таблицы, часовой пояс проекта Apps Script и форматирование даты. Используй одну IANA-зону для всех операций и не меняй дату договора через фиксированное смещение вроде PST или GMT+3. Покажи, где задан часовой пояс, и добавь тест с датой без времени.

После исправления проверь дату на тестовой строке. Отдельно проверь дату в названии файла и внутри документа.

3. Раздели создание и отправку. Если документ создаётся, но уведомление не уходит, попроси:

Раздели статусы создания документа и отправки уведомления. Статус created ставь только после успешного создания и сохранения документа. Для уведомления используй отдельный статус notification_sent. При ошибке отправки не создавай новый документ, сохрани ссылку на готовый документ и запиши текст ошибки в error_message.

Так можно повторить отправку без повторной генерации договора.

4. Обработай несколько строк. Если при одновременной загрузке часть строк не обрабатывается, используй очередь:

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

Такой режим удобнее, чем запускать отдельную обработку на каждую новую строку.

5. Переподключи доступ. Последней проверяй OAuth-проблему, когда таблица выглядит подключённой, но скрипт получает ошибку доступа:

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

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

Сколько стоит своя схема и кому она не подойдёт?

Для Apps Script зафиксированы такие лимиты:

• 250 созданных документов в день для обычного аккаунта без Workspace;
• 90 минут работы триггеров в день;
• 6 минут на один запуск;
• 20 установленных триггеров на пользователя для одного скрипта.

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

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

Платная подписка помощника остаётся отдельной постоянной статьёй расходов. Стоимость Google Workspace или другого аккаунта тоже нельзя включать в слово «бесплатно» без конкретных условий.

Как начать, если технологии раздражают?

Мой маршрут для клиники выглядит так:

1. Выписать отдельно пациента, плательщика, услугу и подписанта.
2. Добавить дату договора и основание оплаты.
3. Сделать одну тестовую строку с вымышленными данными.
4. Поставить переменные в один шаблон Google Docs.
5. Попросить помощника связать заголовки и переменные.
6. Проверить пустые поля и незаменённые переменные.
7. Только после этого включить обработку новых строк.
8. Telegram оставить на потом.

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

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

Вопросы и ответы

Это собирательная история выпускников практикума, а не рассказ одного человека: так эта работа устроена в большинстве таких дел.