Статусная модель в 1С: что это и как работать со статусами документов

Статусная модель в 1С — это механизм, который описывает жизненный цикл объекта (документа, заказа, заявки) через последовательность состояний: «Черновик», «На согласовании», «Утверждён», «В работе», «Закрыт» и т.д. Каждый статус фиксирует конкретный этап обработки и определяет, какие действия с объектом сейчас разрешены, а какие — заблокированы.

В типовых конфигурациях статусы встречаются повсеместно: у заказов клиентов в «1С:Управление торговлей», у заявок на расходование средств в «1С:ERP», у кадровых документов в «1С:ЗУП», у задач в «1С:Документооборот». Понимание статусной модели необходимо и пользователю, который хочет понять, почему документ «не проводится», и разработчику, который проектирует собственный процесс согласования.

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

Из чего состоит статусная модель

Технически статусная модель в 1С строится из нескольких элементов. Первый — перечисление со списком возможных статусов (например, «СтатусыЗаказовКлиентов»). Второй — реквизит объекта, хранящий текущий статус. Третий — логика переходов: проверки в процедурах «ПриЗаписи», «ОбработкаПроведения» или в коде бизнес-процессов, которые разрешают или запрещают смену статуса.

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

Важно различать статус и признак проведения документа. Проведение отвечает за движения по регистрам (проводки, остатки), а статус — за этап бизнес-процесса. Документ может быть проведён, но находиться в статусе «На согласовании», или наоборот — быть утверждённым, но ещё не проведённым.

Как статусы работают в типовых конфигурациях

В «1С:Управление торговлей» и «1С:ERP» у заказов клиентов есть предопределённые статусы: «К отгрузке», «Ожидается оплата», «Готов к закрытию», «Закрыт» и др. Статусы связаны с состояниями расчётов и отгрузки: система сама рассчитывает, можно ли перевести заказ дальше, и блокирует переход, если, например, по заказу не оформлена реализация.

В «1С:Документооборот» статусная модель тесно связана с бизнес-процессами: документ проходит этапы «Регистрация → Рассмотрение → Согласование → Утверждение», и переход между ними выполняет не пользователь вручную, а процесс по маршруту. В «1С:ЗУП» статусы («Подготовлен», «Согласован», «Принят») управляют тем, попадает ли кадровый документ в учёт.

Как спроектировать статусную модель для своего процесса

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

Для каждого перехода определите три вещи: кто имеет право его выполнить, какие условия должны быть выполнены (заполненность реквизитов, наличие связанных документов) и что происходит при переходе (уведомления, создание задач, движения по регистрам). Переходы «назад» — возврат на доработку — тоже нужно предусмотреть явно, иначе пользователи начнут обходить модель.

1. 1
   Нарисуйте схему состояний и переходов, согласуйте её с владельцем процесса
2. 2
   Создайте перечисление статусов и реквизит объекта
3. 3
   Реализуйте проверки допустимости переходов (в коде или через бизнес-процессы)
4. 4
   Добавьте регистр истории статусов с фиксацией пользователя и времени
5. 5
   Настройте права: кто может переводить объект на каждый следующий этап
6. 6
   Протестируйте все переходы, включая возвраты и отмену
7. 7
   Настройте отчёт или рабочее место для контроля объектов по статусам

Реализация: простой вариант против бизнес-процессов

Простой вариант — реквизит «Статус» плюс проверки в модуле объекта. Он подходит, когда переходы линейны, а согласующих один-два. Проверка выглядит как сравнение старого и нового значения статуса и выдача отказа при недопустимом переходе. Такой подход легко отладить и он не требует подсистемы бизнес-процессов.

Сложный вариант — механизм бизнес-процессов и задач (БСП или «1С:Документооборот»). Он нужен, когда маршрут ветвится, участвуют несколько ролей, требуются эскалации по срокам и параллельное согласование. Цена решения — заметно более сложная разработка и администрирование.

Если Не СтатусПереходДопустим(СтарыйСтатус, НовыйСтатус) Тогда
    ВызватьИсключение "Переход из статуса """ + СтарыйСтатус + """ в """ + НовыйСтатус + """ запрещён";
КонецЕсли;

Контроль и отчётность по статусам

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

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

Типичные ошибки и риски

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

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

FAQ: частые вопросы о статусной модели