Где в 1С хранить статус документа и как его менять

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

Разберём, как создать статус тремя способами — от простого реквизита справочника до бизнес-процесса, как настроить автоматическую смену статуса по условию и как потом отобрать документы по статусу в списке. Все примеры — под 1С:Предприятие 8.3, интерфейс «Такси».

Три механизма статуса: какой выбрать под задачу

Прежде чем лезть в конфигуратор, определитесь, что именно вам нужно от статуса. От этого зависит механизм — переделывать потом дороже.

Короткая логика выбора:

• 🟢 Фиксированный набор состояний, историю вести не нужно — реквизит с перечислением.
• 🟡 Пользователи должны сами заводить новые статусы — реквизит со ссылкой на справочник.
• 🔵 Важно, кто и когда переключил статус — периодический регистр сведений .
• 🟣 Статус = этап согласования с поручениями ответственным — бизнес-процесс.

Статус через реквизит с типом «Перечисление»

Это базовый способ. Подходит, когда список статусов известен заранее и не меняется в работе.

Шаг 1. Создайте перечисление. В дереве конфигурации — ветка Перечисления, добавьте новый объект, например СтатусыЗаказа. На закладке Данные впишите значения: Новый, ВРаботе, Отгружен, Закрыт. Задайте им синонимы — именно синоним увидит пользователь.

Шаг 2. Добавьте реквизит объекту. Откройте нужный справочник или документ, на закладке Данные добавьте реквизит Статус, тип — ПеречислениеСсылка.СтатусыЗаказа.

Шаг 3. Выведите на форму. Откройте форму элемента (или документа), перетащите реквизит Статус из состава реквизитов на форму. Пользователь получит поле выбора со значениями перечисления.

Присвоить статус из кода — одна строка:

Объект.Статус = Перечисления.СтатусыЗаказа.ВРаботе;

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

Динамический статус в периодическом регистре сведений

Реквизит хранит только текущее значение. Как только нужен ответ на вопрос «а какой статус был в прошлый вторник и кто его поставил» — переходите на периодический регистр сведений.

Как устроить регистр:

1. Добавьте объект РегистрыСведений → СтатусыЗаказа.
2. Периодичность — В пределах секунды (на закладке свойств регистра). Это и даёт историю по датам.
3. Измерение (Данные → Измерения): Заказ, тип — ссылка на ваш документ или справочник. Отметьте его Ведущее.
4. Ресурс: Статус, тип — ПеречислениеСсылка.СтатусыЗаказа.
5. По желанию — реквизит Автор с типом СправочникСсылка.Пользователи, чтобы фиксировать, кто сменил.

Записать смену статуса (например, из команды формы):

Запись = РегистрыСведений.СтатусыЗаказа.СоздатьМенеджерЗаписи();
Запись.Период = ТекущаяДата();
Запись.Заказ  = ТекущийЗаказ;
Запись.Статус = Перечисления.СтатусыЗаказа.Отгружен;
Запись.Записать();

Получить текущий статус — через срез последних на нужную дату. Метод ПолучитьПоследнее возвращает структуру с ресурсами:

Отбор = Новый Структура("Заказ", ТекущийЗаказ);
Значения = РегистрыСведений.СтатусыЗаказа.ПолучитьПоследнее(ТекущаяДата(), Отбор);
ТекущийСтатус = Значения.Статус;

Если нужна вся история смен (таблица «когда → какой статус → кто»), стройте запрос к виртуальной таблице регистра без слова СрезПоследних — она вернёт все записи по заказу.

Статусы в бизнес-процессах и задачах

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

Коротко, из чего это собирается:

• Объект Задача — что и кому поручено. У задачи есть адресация (кому): роль, подразделение, конкретный пользователь.
• Объект Бизнес-процесс — сам маршрут. На карте маршрута расставляете точки: Старт, Действие, Условие, Завершение.
• Точки Действие генерируют задачи. Пока задачи по точке не выполнены, процесс стоит на ней — это и есть текущий «статус».
• Точки Условие разводят маршрут по ветвям (например, «Сумма больше лимита» → дополнительное согласование).

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

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

Это самый трудоёмкий способ: карту маршрута, адресацию и формы задач нужно спроектировать и отладить. Берите его только там, где действительно есть поток согласований, а не ради трёх состояний документа. Для простого «Новый / В работе / Закрыт» бизнес-процесс — избыточен.

Автоматическая смена статуса по условию

Чаще всего статус не выбирают руками, а пересчитывают по данным объекта: заполнили дату отгрузки — статус «Отгружен», оплатили полностью — «Закрыт». Главный вопрос — где разместить этот код.

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

Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
    Если ЗначениеЗаполнено(ДатаОтгрузки) Тогда
        Статус = Перечисления.СтатусыЗаказа.Отгружен;
    КонецЕсли;
КонецПроцедуры

Вариант 2. По команде на форме. Кнопка «Перевести в работу» вызывает серверную процедуру, которая меняет статус и записывает объект. Удобно, когда переход нужно сопроводить проверками («нельзя закрыть неоплаченный заказ»).

Вариант 3. Регламентным заданием. Если статус зависит от внешних данных (пришла оплата, наступил срок), заводят регламентное задание, которое по расписанию обходит объекты и меняет статусы пачкой.

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

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

• Проверка роли прямо в коде перехода: перед сменой статуса сравниваете текущего пользователя с допустимым списком и при несовпадении ставите Отказ = Истина.
• Доступность кнопки на форме по роли — тогда кнопка «Закрыть заказ» просто не видна тем, кому закрывать нельзя.
• Ограничение на уровне записей (RLS), если статус хранится в регистре и доступ нужно резать по организации или подразделению.

Любой переход полезно логировать: достаточно писать в регистр сведений автора и дату, как в способе с динамическим статусом. Тогда на вопрос «кто перевёл документ в этот статус» всегда есть ответ.

Как показать статус в списке и отобрать по нему

Сделать статус мало — им ещё пользуются в списках. Две типовые доработки.

Цветом или значком в динамическом списке. В форме списка настраивается условное оформление: по значению поля Статус задаётся цвет строки или текста. Открываете настройку оформления списка, добавляете условие (Статус Равно «Закрыт») и выбираете оформление. Код для этого не нужен — всё в настройках формы.

Отбор по статусу. Пользователю дают быстрый отбор: в настройке динамического списка выносите поле Статус в пользовательские настройки отбора. Тогда в списке появится поле, где можно оставить только «В работе».

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

Ошибки, которые ломают работу со статусами

Типичные грабли, на которые наступают при первой реализации статусов:

• 🔴 Статус как строка. Реквизит типа Строка, куда вписывают «отгружен», «Отгружено», «отгр.». Отбор и отчёты по такому полю не работают из-за разнобоя. Всегда ссылочный тип — перечисление или справочник.
• 🔴 Нет значения по умолчанию. Новый документ создаётся с пустым статусом, и отбор «только новые» его не находит. Задайте начальный статус в обработчике ПриСозданииНаСервере или ОбработкаЗаполнения.
• 🔴 Логика перехода в двух местах. Кнопка на форме ставит один статус, ПередЗаписью — другой, и они конфликтуют. Один механизм перехода на один статус.
• 🔴 Регистр без ведущего измерения. Если удалить заказ, записи о его статусах в регистре останутся висеть. Пометьте измерение Заказ как ведущее — тогда записи удалятся вместе с объектом.
• 🔴 Перечисление там, где нужен справочник. Добавить статус в перечисление можно только через конфигуратор и обновление. Если бизнес регулярно просит новые состояния — сразу делайте справочник.

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