Процессуальный срок в CRM: основание, расчёт и проверка

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

Одна карточка дела, две разные даты

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

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

Сначала определяют норму, потом считают дни

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

Например, статья 107 ГПК РФ связывает начало течения периода со следующим днём после определяющей даты или события. Для сроков в днях она предусматривает исключение нерабочих дней, если Кодексом не установлено иное. Здесь речь именно о правилах ГПК, а не обо всех сроках в любой информационной системе.

Что сохранять рядом с результатом расчёта

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

Исходное событие нельзя подменить датой ввода

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

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

Окончание срока — отдельная часть проверки

Недостаточно правильно отсчитать начало периода. В статье 108 ГПК РФ отдельно описаны окончание сроков в месяцах и годах и ситуация с последним нерабочим днём. Та же статья различает общее правило последнего дня и действия непосредственно в суде или организации с установленным временем окончания работы либо операций.

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

Как показать воспроизводимый расчёт

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

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

Что происходит при новых обстоятельствах

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

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

Проверить механизм можно без настоящего дела

1. Создайте вымышленную карточку и оставьте исходное событие неподтверждённым. Программа не должна показывать окончательный проверенный срок.
2. Задайте учебное правило и календарь для теста. Проверьте воспроизводимость шагов, не называя тест юридическим расчётом реального дела.
3. Разведите дату готовности проекта и процессуальный предел. Перенос первой не должен менять второй.
4. Исправьте исходное событие с причиной. Сохраните прежнюю версию и направьте новый результат на проверку.
5. Измените существенное условие способа действия. Система должна запросить повторное подтверждение применимого окончания.
6. Откройте карточку под ролью другого исполнителя. Он должен понимать, что проверено, что предварительно и за какой следующий шаг отвечает.

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