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

> Я собрала схему, где из одной строки Google Таблицы получается договор по шаблону. Ниже пошаговая сборка, промпты и проверки для клиники.

Источник: https://vibeceh.ru/cases/dogovory-po-shablonam-v-tablice
Автор: Сергей Мазур · опубликовано 2026-08-14

У меня появилась [Google Таблица](/concepts/google-tablicy), где отдельно стоят пациент, плательщик, услуга и подписант, а из одной заполненной строки автоматически собирается готовый договор по шаблону. Так договоры по шаблонам в клинике перестают зависеть от ручной перепечатки. Для клиники это ценнее, чем просто сэкономить набор текста: схема не даёт перепутать участников сделки и подсвечивает пустые обязательные поля.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

![Кот смотрит на схему цепочки от строки таблицы до ссылки в таблице.](https://s3.regru.cloud/crossmark/statejnik/images/guides/dogovory-po-shablonam-v-tablice/kadr-1.webp)

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

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

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

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

```text
patient
payer
service
signer
contract_date
document_url
status
```

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

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

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

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

Apps Script часто используется для замены текста в документах».

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

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

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

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

Для сборки нужны Google-аккаунт, Google Таблица с правами редактора, шаблон Google Docs и проект Apps Script. Скрипту понадобятся разрешения на работу с таблицей, документами и Google Диском. Telegram оставь необязательным уведомлением, а не частью генерации договора, чтобы цепочка сборки оставалась короткой и понятной.

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

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

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

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

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

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

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

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

![Кот поднимает лапу рядом с тремя карточками этапов сборки договора.](https://s3.regru.cloud/crossmark/statejnik/images/guides/dogovory-po-shablonam-v-tablice/kadr-2.webp)

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

   

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

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

   

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

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

   

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

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

   

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

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

   

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

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

   

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

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

   

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

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

   

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

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

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

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

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

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

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

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

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

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

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

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

![Человек со спины закрывает лицо ладонями рядом с причинами сбоев генерации.](https://s3.regru.cloud/crossmark/statejnik/images/guides/dogovory-po-shablonam-v-tablice/kadr-3.webp)

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

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

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

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

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

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

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

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

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

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

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

Своя связка требует Google Таблицу, Google Docs, Apps Script и платную подписку помощника. Рублёвое сравнение зависит от конкретных условий и тарифов, поэтому общей суммы здесь не даю. Apps Script для обычного аккаунта ограничен 250 созданными документами в день, 90 минутами триггеров и 6 минутами на один запуск.

| Вариант | Что получает клиника | Ограничение |
|---|---|---|
| Своя связка | Таблица, шаблон, проверка полей, ссылка на документ | Нужны сборка, тестирование и контроль доступов |
| Готовый сервис | Готовый интерфейс и стандартные сценарии | Настройка зависит от возможностей и поддержки |
| Подрядчик | Сборка под задачу сторонним специалистом | Изменения и исправления зависят от подрядчика |
| Ручное заполнение | Ничего не нужно настраивать | Данные приходится переносить и перепроверять руками |

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

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

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

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

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

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

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

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

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

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

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

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

Договор из строки можно собирать через Google Таблицы, Google Docs и Apps Script, если поля и переменные заранее согласованы. Таблица хранит данные, шаблон хранит текст, а скрипт соединяет их. Сложные формы, юридическую проверку и нестандартные условия нужно проверять отдельно.

Отдельная готовая программа не обязательна. Для базовой схемы достаточно Google Таблицы, Google Docs и Apps Script. Помощник [Claude Code](/guides/claude-code-dlya-ne-kodera-pervyj-zhivoj-sajt) нужен для сборки логики, но готовый договор создаётся внутри связки Google-сервисов.

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

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

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

Excel подходит для хранения данных, но конкретная автоматизация зависит от версии Excel, макросов и среды, где будет создаваться документ. Таблица по договорам в эксель может стать первым шагом такого журнала, но для описанной схемы проще использовать Google Таблицы и Google Docs. Word и VBA добавляют отдельные настройки и повышают порог входа.

Раздели колонки по смыслу: данные пациента, данные плательщика, услуга, подписант, дата, статус и ссылка. Так таблица договоров в экселе остаётся прозрачной, а таблица учета договоров в excel не превращается в кашу. Не смешивай несколько реквизитов в одной ячейке. Для автоматической генерации понадобится отдельный механизм связи Excel с шаблоном Word.

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

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

Заполни обязательные поля в строке, поставь статус `NEW` и запусти обработчик. Apps Script проверит данные, скопирует шаблон Google Docs, заменит переменные и запишет ссылку в `document_url`. Открой документ и проверь его до отправки.

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

Добавь статусы `NEW`, `creating`, `created` и проверку заполненной ссылки. Перед созданием скрипт должен проверять статус и `document_url`. Также проверь, что в проекте не создано несколько одинаковых триггеров.

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

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

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

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

- [Расширить Документы Google с помощью Apps Script](https://developers.google.com/apps-script/guides/docs?hl=ru)
- [Class Range, Apps Script](https://developers.google.com/apps-script/reference/spreadsheet/range)
- [Installable Triggers, Apps Script](https://developers.google.com/apps-script/guides/triggers/installable)
- [Квоты для сервисов Google Apps Script](https://developers.google.com/apps-script/guides/services/quotas?hl=ru)
- [Веб-приложения Apps Script](https://developers.google.com/apps-script/guides/web?hl=ru)
- [Как я научил бухгалтерию составлять договора дарения со скоростью 1 договор в 4 секунды](https://habr.com/ru/articles/843488/)
- [Автоматизируй это: как бесплатно создать конструктор договоров в Google Docs](https://vc.ru/legal/192774-avtomatiziruy-eto-kak-besplatno-sozdat-konstruktor-dogovorov-v-google-docs)
- [Auto Fill a Google Doc Template from Google Sheet Data](https://gist.github.com/loredonrj/cdcca6eeae02b403a2ff9f36b3877282)
- [Google Apps Script: создание PDF из активной строки](https://gist.github.com/andrewroberts/8985d5d0a50c905ed43b639a97c2035f)

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