Автоматизация учёта договоров: реестр, сроки и ответственные

Как спроектировать внутренний реестр договоров: карточка и редакции, контроль сроков, ответственные, права доступа, напоминания и критерии приёмки.

Автор: Александр Поркулевич, CEO и основатель, 404gen.

Сначала найдите место, где теряется действие

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

Разведите хранение, согласование и исполнение. Хранилище отвечает за доступный файл и его происхождение. Согласование — за маршрут замечаний и решения участников. Учёт исполнения — за актуальные события, сроки и владельцев задач. Эти функции могут жить в одном продукте, но у них разные состояния. Кнопка «Согласовано» не означает, что договор подписан, вступил в действие или полностью исполнен. Такой переход должен иметь собственное основание.

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

Определите границы карточки договора

Карточка — это объект учёта, а файл — его вложение или редакция. У одного договора могут быть приложения, дополнительные соглашения, спецификации и несколько сканов. Номер на бумаге не всегда уникален в масштабах компании: его могут повторять разные контрагенты и подразделения. Для системы нужен устойчивый внутренний идентификатор, а для пользователя — понятные реквизиты, по которым документ можно найти и отличить от похожего.

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

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

Разделите состояние документа и состояние задачи

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

Переходы описываются через разрешённое действие и последствия. Кто может закрыть карточку? Что происходит с будущими напоминаниями? Можно ли вернуть завершённый документ в работу и по какой причине? Не делайте все статусы свободно редактируемым списком. Иначе сотрудник получит возможность случайно пропустить обязательную проверку или скрыть просрочку простым переименованием состояния.

Храните редакции вместе с происхождением

Файл с названием «финал_новый_точно» не задаёт надёжную версию. Сохраняйте идентификатор редакции, время загрузки, автора, исходное имя и связь с предыдущей записью. Отдельно отмечайте, какой файл выбран актуальным для конкретной цели. Актуальный текст для обсуждения и подтверждённый подписанный экземпляр могут различаться. Система должна помогать это увидеть, а не придавать любому последнему вложению статус оригинала.

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

Одновременная работа требует проверки актуальности. Один сотрудник открыл карточку, второй назначил новую редакцию, первый нажал «Подтвердить». Рабочая система должна заметить, что основание изменилось, и предложить повторный просмотр. В концепте «Параграф» это показано локальной сменой редакции: прежняя проверка перестаёт разрешать подтверждение. Такой макет демонстрирует правило интерфейса; серверная защита должна быть реализована и проверена отдельно.

Срок должен иметь тип и источник

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

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

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

Напоминание не равно выполненному обязательству

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

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

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

Ответственный — это роль в процессе

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

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

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

Права проверяются за пределами интерфейса

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

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

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

Назначьте источник истины для каждого поля

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

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

Переезд из таблицы — отдельный этап. До загрузки проверьте дубли, форматы дат, пустые значения, владельцев и доступность файлов. Импортированный статус не становится достоверным автоматически: часть карточек может требовать подтверждения ответственным. Сохраните источник строки и отчёт загрузки. Если в таблице не было истории редакций, новый продукт не сможет восстановить её из текущего файла; это ограничение нужно назвать прямо.

Какие ограничения должна удерживать база

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

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

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

Принимайте систему по историям, а не по числу экранов

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

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

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

Что подготовить для оценки собственной CRM-функции

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

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

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

Частые вопросы

Можно ли автоматизировать учёт договоров в существующей CRM?

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

Реестр может сам определить дату продления?

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

Зачем хранить старые редакции?

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

Можно ли начать без интеграции с учётной системой?

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

Источники и пример интерфейса

Технические основы контроля связей описаны в документации PostgreSQL об ограничениях данных, а особенности параллельной работы — в разделе об изоляции транзакций. Они не определяют правовой статус договоров; правила процесса и хранения компания согласует отдельно.

Для подготовки данных пригодится материал об импорте Excel и проверке строк. В концепте «Параграф» показаны реестр, редакция и контрольное действие на вымышленных данных. Если требуется собственный процесс поверх нескольких источников, обсудим разработку CRM на заказ: обследование, границу первой версии, права и критерии приёмки.