Автоматизация учета договоров означает живой реестр обязательств: после подписания каждый договор попадает в таблицу со сторонами, версиями, сроками, условиями пролонгации и ответственными, а система заранее напоминает о датах. Модель вытаскивает поля из подписанного документа, юрист утверждает каждую запись. Подготовка и согласование текста договора остаются за пределами этой схемы, они разобраны в других материалах.
Зачем нужен реестр
Реестр договоров заполняется из подписанных документов: модель предлагает значения полей, скрипт проверяет их на полноту, юрист утверждает запись, а напоминания о сроках рассылает система.
Пока договоры лежат папками на общем диске, ответ на вопрос «что действует прямо сейчас и до какого числа» собирается вручную. Продление проходит молча, потому что условие автоматической пролонгации прочитали при подписании и забыли. Ответственный уходит в отпуск, а уведомление контрагента требовало отправки именно в этот период. Реестр превращает такие ситуации в заранее видимые события.
Граница темы такая. Как подготовить договор, согласовать правки и подписать, описывает материал про маршрут договора от заявки до архива. Здесь договор уже подписан, а задача иная: удержать в поле зрения всё, что он обещает сторонам во времени. Поиск по базе текстов на естественном языке закрывает отдельный разбор бота для поиска по договорам; реестр отвечает на вопросы о датах и обязанностях по строгим полям.
Владельцем реестра назначается конкретный человек, чаще всего юрист или руководитель договорного отдела. Он определяет перечень полей, утверждает записи и разбирает исключения. Система хранения может быть любой: от таблицы до специализированной программы. Важно, чтобы запись связывалась с исходным файлом, а изменение любого поля оставляло след с датой и автором.
Поля реестра
Набор полей определяют вопросы, которые компании приходится задавать себе регулярно. Кто контрагент и какая версия договора действует? До какого числа он продолжает действовать? Что произойдёт при бездействии сторон? Кто в компании ведёт отношения? Чем меньше полей, тем легче их проверять, поэтому каждое поле должно отвечать на реальный вопрос. Поле «на всякий случай» откладывают до момента, когда вопрос появится: пустые колонки быстро теряют доверие у тех, кто пользуется реестром.
| Поле | Откуда берётся | Кто подтверждает |
|---|---|---|
| Стороны и реквизиты | Преамбула и раздел реквизитов подписанного файла | Юрист |
| Версия и дополнительные соглашения | Список приложенных документов и даты подписания | Юрист |
| Срок действия | Раздел о сроке, с учётом дополнительных соглашений | Юрист |
| Условия пролонгации и расторжения | Раздел о продлении, порядок уведомления | Юрист, затем владелец договора |
| Платёжные условия | Раздел об оплате, график платежей | Бухгалтер |
| Ответственный в компании | Назначение внутри компании, вне текста договора | Руководитель подразделения |
Строка «Ответственный в компании» показательна: из подписанного файла его часто извлечь невозможно, в тексте его нет. Такие поля заполняет человек: руководитель подразделения указывает ответственного в момент загрузки договора, а запись без него остаётся черновиком. Значит, схема извлечения обязана допускать пустое значение с пометкой «в документе отсутствует», вместо подстановки правдоподобного ответа.
Для условий пролонгации и расторжения копируется цитата пункта целиком, рядом с кратким пересказом. Так же поступают с порядком уведомления сторон и с условиями оплаты. Юрист сверяет пересказ с цитатой за секунды, а будущие споры о смысле пункта решаются по тексту. Без цитаты пересказ превращается в мнение модели о содержании договора.
Сроки и напоминания
Напоминания живут в обычной календарной логике, и модель остаётся в стороне от них. Скрипт читает утверждённые даты и в нужный момент отправляет сообщение ответственному: договор подходит к окончанию, срок уведомления о продлении наступает, очередной платёж по графику приближается. Окно напоминания задаётся правилом компании для каждого типа договоров.
Важная деталь касается дат окончания. Договор способен продлеваться по условию либо прекращаться по сроку, и для реестра различие принципиально. Запись содержит оба признака: плановую дату окончания и вид последствия. Если условие сформулировано двусмысленно, запись получает статус «спорное» и уходит юристу. Записи со спорным условием продлевать автоматически нельзя: решение принимает человек.
Напоминание должно содержать ссылку на исходный документ и цитату нужного пункта. Тогда получатель открывает сообщение и видит, о чём речь, без поиска по папкам. Выполнение действия фиксируется в той же записи: отправлено уведомление, продлён договор, подписано соглашение. Закрытая запись показывает, кто и когда принял решение, и на этот след опирается любой разбор спорной ситуации. Раз в месяц владелец реестра просматривает список записей, где напоминание сработало, а отметки о выполнении нет.
Сроки в российской практике вытекают из условий самого договора и из закона для соответствующего вида отношений. Конкретные правила и периоды юрист сверяет по действующей редакции Гражданского кодекса и отраслевых норм в справочной системе, а сам реестр лишь хранит согласованные юристом даты.
Извлечение и сверка
- Загрузите подписанный файл в хранилище и присвойте ему идентификатор; редактируемая версия остаётся за пределами реестра.
- Распознайте текст, если файл оказался сканом, и сохраните страницы вместе с текстовым слоем.
- Попросите модель заполнить поля по заданной схеме: значение, цитата, номер страницы; при отсутствии данных вернуть пометку «нет в документе».
- Запустите скрипт проверки: заполнены ли обязательные поля, даты в допустимом порядке, цитата действительно встречается в тексте файла.
- Передайте запись юристу на утверждение и только после этого включите напоминания.
Проверка цитаты скриптом закрывает самую неприятную ошибку: модель придумывает пункт, которого нет. Если цитата отсутствует в тексте файла дословно, запись возвращается на доработку автоматически. Остальную работу выполняет юрист, у которого скрипт уже снял механическую часть: он сопоставляет значения с цитатами и решает спорные формулировки.
Договоры содержат реквизиты и персональные данные подписантов. Облачной модели отправляют текст после маскировки таких сведений либо запускают открытую модель на собственном сервере. Правила обработки, ограничения доступа и срок хранения оригиналов остаются в политике компании, реестр оставляет их прежними.
Сколько действующих договоров у вас сейчас без записи о сроках?
Первый запуск
Начинать удобно с одной группы договоров, где даты важнее всего: аренда, абонентское обслуживание, лицензии. Юрист утверждает перечень полей и заполняет вручную пробную партию. Затем модель заполняет те же договоры самостоятельно, и две версии сравниваются поле за полем. Расхождения показывают, какие поля схема извлекает уверенно, а какие всегда нужно заполнять вручную. Для вторых заводят отдельную колонку «заполняет человек» и перестают тратить на них попытки модели. Для первых оставляют выборочную проверку: юрист открывает несколько записей за период и сверяет их с оригиналами.
- Один владелец реестра с правом утверждать записи и менять перечень полей.
- Перечень типов договоров, которые попадают в реестр первыми.
- Правило для спорных записей: срок ответа юриста и действие по умолчанию.
- Журнал изменений с автором, датой и прежним значением каждого поля.
Измерять результат удобно по доле договоров из пробной группы, у которых утверждены все обязательные поля, и по числу пропущенных дат за квартал. Если пропуски сохраняются, причину ищут в маршруте: новый договор попадает в реестр позднее подписания, спустя недели. Решение лежит в маршруте: подпись и загрузка в хранилище объединяются в один шаг процесса.
Возьмите двадцать подписанных договоров одного типа и заполните реестр вручную по пяти полям. Отметьте пункты, над которыми пришлось задуматься или которые пришлось перечитывать: эти места и станут ядром схемы для модели. Контур с проверкой цитат и напоминаниями собирается под конкретные документы, расскажите нам о вашей обработке договоров.