Реальная автоматизация 1С: как получить статус

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

Запрос «как получить статус» на практике означает три разные задачи. Первая — увидеть статус в интерфейсе: в списке документов, в карточке заказа, в журнале обмена. Вторая — получить статус программно: в запросе, в отчёте, в интеграции через HTTP или COM. Третья — настроить автоматическую смену статусов, чтобы система сама переводила заказ из «В работе» в «Отгружен» по событию. Ниже разобраны все три сценария с проверкой результата.

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

Где 1С хранит статусы: три типовых варианта

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

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

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

Как увидеть статус в интерфейсе без программирования

В списке документов статус часто скрыт настройками. Откройте журнал документов, перейдите в «Ещё → Изменить форму» (или «Настройка списка» в управляемых формах) и добавьте колонку «Статус». В типовых конфигурациях на управляемых формах колонка может называться «Состояние» и выводиться пиктограммой — тогда расшифровка доступна по наведению курсора или в карточке документа.

Для обменов данными статус смотрят в журнале регистрации и в форме «Результаты обмена данными» (в конфигурациях с БСП — «Администрирование → Синхронизация данных»). Там видно, завершился ли обмен успешно, были ли предупреждения и незарегистрированные объекты. Для фоновых заданий статус проверяется в «Администрирование → Обслуживание → Регламентные и фоновые задания»: там видны состояния «Выполняется», «Завершено», «Ошибка» и текст последней ошибки.

1. 1
   Откройте журнал нужного вида документов
2. 2
   Через «Ещё» откройте настройку формы или списка
3. 3
   Добавьте в выбранные поля реквизит «Статус» или «Состояние»
4. 4
   Сохраните настройку и проверьте, что колонка заполнена для проведённых документов
5. 5
   Если колонка пустая — проверьте, не хранится ли статус в регистре сведений

Если статус нужен регулярно и массово, удобнее сделать отчёт через «Ещё → Отчёты» или универсальный отчёт по регистру сведений статусов. Это не требует доработки конфигурации и доступно пользователю с правами на отчёты.

Как получить статус программно: запрос и код

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

ВЫБРАТЬ
	ЗаказКлиента.Ссылка КАК Заказ,
	ЗаказКлиента.Статус КАК Статус
ИЗ
	Документ.ЗаказКлиента КАК ЗаказКлиента
ГДЕ
	ЗаказКлиента.Дата >= &НачалоПериода
	И ЗаказКлиента.Проведен

Когда статус хранится в регистре сведений, запрос соединяет документ с регистром. Для периодического регистра берут срез последних — иначе получите всю историю вместо текущего значения. Это самая частая ошибка новичков: запрос возвращает десять строк на один заказ, и отчёт «задваивает» суммы.

ВЫБРАТЬ
	СтатусыСрез.Объект КАК Документ,
	СтатусыСрез.Статус КАК ТекущийСтатус
ИЗ
	РегистрСведений.СтатусыДокументов.СрезПоследних(&ТекущаяДата, ) КАК СтатусыСрез

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

Как получить статус извне: HTTP, COM и файловый обмен

Интеграционный сценарий — когда статус нужен внешней системе: сайту, CRM, складской программе. В конфигурациях на базе БСП есть типовые механизмы: публикация HTTP-сервисов, REST-интерфейс OData (включается в настройках публикации информационной базы) и планы обмена. OData позволяет читать реквизиты объектов, включая статус, стандартными GET-запросами без доработки кода.

Ограничение OData — он отдаёт то, что хранится в объекте. Вычисляемые состояния и статусы из регистров сведений через стандартный OData получить сложнее; для них публикуют отдельный HTTP-сервис с методом, который возвращает нужное значение в JSON. Такой сервис должен проверять авторизацию и не отдавать лишних данных — открытый наружу метод без контроля доступа это прямая угроза утечке.

Файловый вариант — выгрузка статусов в CSV или XML регламентным заданием — проще в настройке и безопаснее, но даёт задержку. Он подходит, когда внешней системе достаточно данных с периодичностью раз в час или раз в день.

Автоматическая смена статусов: как настроить и не сломать учёт

Автоматизация статусов строится на трёх механизмах. Подписки на события срабатывают при записи объекта: например, при проведении документа оплаты заказ переводится в «Оплачен». Регламентные задания проверяют условия по расписанию: заказы в статусе «В работе» дольше заданного срока переводятся в «Просрочен». Бизнес-процессы двигают статус по маршруту согласования.

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

Как проверить, что статус получается и меняется корректно

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

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

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