Перейти к содержимому

Готовность заказов: как считается статус

Актуально на 03.10.2026. Область: заказы покупателя (Документ.АСЕРВИС_ЗаказПокупателя), техкарты, заявки на доставку.

Статья отвечает на вопросы «почему у заказа именно такая иконка», «почему статус не изменился» и «почему заказ закрылся или снова открылся».

Основа расчёта — сравнение планового и фактического значения по каждому этапу. Этап не хранит «прогресс» в процентах: состояние всегда пересчитывается из документов.

План больше нуля и факт равен нулю — «не начато». План больше нуля и факт меньше плана — «в работе». План больше нуля и факт равен плану — «завершено». План больше нуля и факт больше плана — «проблема» (перерасход). План равен нулю — этап не контролируется, клетка пустая.

Схема одинаково работает и для количественных этапов (производство, закупка, доставка, выпуск), и для суммовых (оплата, отгрузка, верификация бухгалтерией).

Состояние Смысл Условие
пусто этап не контролируется план равен нулю
«не начато» работу не начинали план > 0, факт = 0
«в работе» выполнено частично план > 0, 0 < факт < план
«завершено» выполнено ровно по плану план > 0, факт = план
«проблема» выполнено больше плана план > 0, факт > план

Два уточнения к правилу:

  • Суммовые этапы сравниваются копейка в копейку. Оплата, отгрузка и получение документов считаются завершёнными, только когда сумма совпала с суммой заказа с точностью до копейки. Недоплата и переплата одинаково означают незавершённый этап; переплата даёт состояние «проблема». Сравнение идёт по значениям, округлённым до двух знаков, поэтому доли копейки завершению не мешают.
  • Количественные этапы допускают превышение плана. Выполнить больше задания можно — «сверх заказа» не считается ошибкой, но состояние такого этапа будет «проблема», и заказ из-за него не закроется, пока расхождение не разберут.

Значения «не требуется» и «отменено», оставшиеся в классификаторе состояний, расчётом не возвращаются: неконтролируемый этап показывается пустой клеткой.

Все места, где видна готовность, используют одну и ту же картинку-спрайт, поэтому иконки означают одно и то же и в журнале, и в карточке заказа, и в дереве заявок:

Что видно Когда
пустая клетка план не задан, этап не контролируется
«не начато» факт равен нулю
«в работе» 0 < факт < план
«завершено» факт равен плану
«проблема» факт больше плана

Формы не сопоставляют состояния с иконками сами: они получают уже готовый номер картинки, поэтому раскладка совпадает во всех журналах и формах.

Этапов бизнес-процесса шесть:

№ Этап Что контролирует Источник факта Условие завершения
1 Оплата деньги по заказу оплаты по заказу оплачено ровно на сумму заказа
2 Производство работы по техкартам регистр производства факт не меньше задания по каждому включённому цеху
3 Закупка материалы под заказ очередь закупки факт не меньше плана
4 Доставка доставка по заказу доставка заказов факт не меньше плана
5 Отгрузка передача со склада проведённые реализации отгружено ровно на сумму заказа
6 Верификация бухгалтерией возврат документов от клиента флажок «Документы получены» в реализации получено ровно на сумму заказа

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

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

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

  1. Изменение факта. Проведение, отмена проведения, изменение или удаление документа (заказ, реализация, поступление, платёж, заявка на доставку, документы цехов, техкарты) вызывает пересчёт.
  2. Определение затронутых заказов. По документу вычисляется список заказов, которых он касается, и набор затронутых контуров. Документ, который меняет только суммы (платёж, реализация), вызывает пересчёт суммовых этапов и завершения, не затрагивая производство и закупку.
  3. Расчёт контуров. Каждый включённый контур считает свой факт и получает состояние по общему правилу «план и факт».
  4. Запись только изменений. Если состояние не изменилось, в регистр состояний ничего не пишется. Повторный пересчёт без изменения документов не порождает ни записи в регистре, ни записи в истории.
  5. История. Каждое фактическое изменение состояния этапа фиксируется в истории готовности: этап, новое состояние, план и факт, вид изменения, документ-источник, дата, пользователь.
  6. Догоняющий пересчёт. Фоновое задание раз в час пересчитывает незавершённые заказы за последние два месяца — страховка от событий, которые могли не сработать, например при массовой загрузке данных.
  7. Пересчёт при обновлении программы. При переходе на релиз 3.0.206.19 статусы проведённых заказов текущего года приводятся в соответствие с документами фоновым обработчиком обновления.
Вид изменения Когда появляется
«Расчет» обычный пересчёт: состояние этапа изменилось
«Ручное изменение» пользователь поставил или снял статус техкарты в очереди или в форме
«Отклонение после закрытия» у закрытого заказа нарушился баланс завершённости
«Отмена» зарезервировано на случай снятия движения

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

Заказ считается закрытым, когда одновременно выполнено всё:

  • отгружено ровно на сумму заказа;
  • оплачено ровно на сумму заказа;
  • получены документы от клиента — если требование по документам не отключено настройкой;
  • нет долга по заказу;
  • нет остатка по закупке и по производству;
  • заказ проведён.

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

Важные особенности критерия:

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

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

Принятая логика:

  1. Отклонение фиксируется, а не растворяется в данных. Программа взводит признак «есть ошибки закрытия» и запоминает дату первого обнаружения; при повторных пересчётах эта дата не сдвигается.
  2. В историю пишется каждый нарушенный этап с видом изменения «Отклонение после закрытия» и с указанием документа, из-за которого пересчёт состоялся. Этапы без плана и завершённые этапы отклонением не считаются.
  3. Оповещение отправляется один раз — в момент появления признака. Повторные пересчёты повторных отправок не дают.
  4. Если баланс восстановился (ошибочный документ исправлен или отменён), признак ошибки и дата снимаются при ближайшем пересчёте.

Дальнейшее поведение зависит от того, как заказ был закрыт:

Как закрыт заказ Что происходит при нарушении баланса
вручную (признак поставил ответственный) заказ остаётся закрытым: дата, поставленная человеком, сохраняется; фиксируется только отклонение
автоматически расчётом при следующем пересчёте расчётный признак завершения и дата закрытия снимаются — заказ снова становится незакрытым, а в истории остаётся отметка об отклонении

Заказы с признаком ошибки закрытия видны в журнале (колонки «Ошибка закрытия» и «Дата ошибки закрытия») и в отчёте «Диспетчеризация заказов», вариант «Отклонения после закрытия». Разбор ведётся по документу-источнику из истории готовности.

Место Что показывается
Журнал заказов, список состояния этапов иконками; отдельно — «Ошибка закрытия» и «Дата ошибки закрытия»
Журнал заказов, вкладка техкарт состояния вёрстки, печати, постпечати, закупки и отгрузки по каждой техкарте заказа
Карточка заказа, таблица продукции состояния по строкам изделий (группа колонок «Статусы готовности»)
Дерево заявок на доставку вёрстка, печать, постпечать и отгрузка со склада готовой продукции по техкартам
Отчёт «Диспетчеризация заказов» варианты «Незавершённые этапы» и «Отклонения после закрытия», а также «Доска заказов», «Заказы в работе», «Застрявшие на этапе», «ГП не отгружена»
Панель «График производства заказа» диаграмма загрузки производства по дням с таблицей работ

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

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

  • Чтение состояния по API. Внешняя система может запросить состояние этапов заказа (в том числе на указанный момент), историю изменений по заказу и поток изменений после заданного момента. Доступ только на чтение и только при наличии прав на чтение заказов покупателей.
  • Оповещения. Смена статуса и появление отклонения после закрытия уходят ответственным через существующий механизм рассылок; при настроенном вебхуке событие передаётся во внешнюю систему (Битрикс24). Повторная отправка одного и того же состояния не выполняется.
  • Состояния не вычисляются при открытии форм и отчётов: читается готовый регистр.
  • Пересчитываются только затронутые заказы и только затронутые контуры.
  • Записываются только реально изменившиеся состояния.
  • История пишется по одной записи на изменение, поэтому она пригодна и для отчётов, и для интеграций.
  • Замеры на рабочей базе: полный пересчёт всех проведённых заказов (около 1 300) занимает несколько секунд, повторный проход без изменений проходит в разы быстрее и не меняет ни одного состояния.
  1. Критерий завершённости. Этапы «Доставка» и «Выпуск продукции» не входят в расчётный критерий завершения заказа: закрытый заказ с незавершённой доставкой не попадает в отклонения после закрытия. Нужно решение бизнеса — расширять критерий или контролировать эти этапы отдельно.
  2. Состояние «отменено». В раскладке иконок для него нет отдельного изображения: в дереве заявок на доставку оно попадает в пустую клетку, в карточке заказа — в «проблему». Нужно единое решение.
  3. Загрузка обменом. Массовая загрузка документов обменом не протоколируется в историю; при необходимости аудита таких изменений потребуется отдельное решение.