Skip to main content
Полный перечень полей — в глоссарии.

​
Что делает этот механизм

Когда ремонтная задача попадает на очередной этап воронки, её ремонтируемая единица инвентаря может автоматически сменить своё состояние. Это единственное место, где движение задачи по воронке напрямую влияет на карточку инвентаря: этап несёт «целевое состояние инвентаря», и как только задача оказывается на этом этапе, состояние привязанной единицы переписывается на это целевое значение. Пример по смыслу: этап «В ремонте» может иметь целевое состояние «Неисправен», а этап «Готово» — целевое состояние «Исправен». Двигая карточку задачи по kanban-воронке, сотрудник заодно, без отдельного действия, переводит саму единицу инвентаря в нужное состояние.

​
Модель данных

Связь этапов воронки с состояниями инвентаря держится ровно на одном поле.
Целевое состояние инвентаря у этапа — единственная точка связи между этапами воронки и состояниями инвентаря. Никаких других правил, привязок или таблиц соответствия «этап → состояние» в модуле нет. Если поле у этапа не заполнено, попадание задачи на этот этап на инвентарь никак не влияет.

​
Логика и побочные эффекты

Перевод состояния срабатывает автоматически при каждом сохранении ремонтной задачи. Проверки идут по порядку, и любая из них может тихо прервать процесс без изменений:
  1. У задачи не указан этап — ничего не происходит.
  2. У этапа не задано целевое состояние инвентаря — ничего не происходит.
  3. У задачи не привязана единица инвентаря — ничего не происходит.
  4. Текущее состояние единицы уже совпадает с целевым — ничего не происходит (лишнее сохранение не выполняется).
Если все четыре условия пройдены (этап есть, целевое состояние задано, единица привязана, и её состояние отличается от целевого), состояние единицы инвентаря переписывается на целевое и единица сохраняется.
Механизм срабатывает при любом сохранении задачи, а не только при смене этапа. Но благодаря последней проверке — «состояние уже совпадает» — повторные сохранения задачи, стоящей на том же этапе, не приводят к лишним записям в инвентарь: перезапись происходит только когда состояние реально должно измениться.

​
Направление только вперёд

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

​
Два независимых основания для недоступности единицы

Целевое состояние этапа и признак этапа «Занимать инвентарь» влияют на доступность единицы по отдельности:
  • признак «Занимать инвентарь» отвечает за вклад самой ремонтной задачи — пока задача открыта и стоит на таком этапе, единица считается занятой ремонтом;
  • целевое состояние отвечает за состояние единицы — если у этого состояния включён флаг «блокирует прокат», единица выведена из проката сама по себе, независимо от того, есть ли по ней открытая задача.
Из-за этого снятие признака «Занимать инвентарь» не всегда делает единицу доступной. Если этап переводит её в состояние с флагом «блокирует прокат», единица останется недоступной по второму основанию — и вернётся в оборот только после смены состояния (вручную или этапом с «исправным» целевым состоянием). Чтобы мастерская вовсе не влияла на доступность, нужно и снять признак у этапов, и убрать у них целевые состояния, блокирующие прокат.

​
Как это используется

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

​
Связанные страницы

Глоссарий: Автосмена состояния инвентаря

Полный перечень полей, участвующих в автоматической смене состояния инвентаря.

Мастерская (ремонтные задачи)

Обзор всего модуля мастерской и его составных частей.

Воронка и задачи

Kanban-воронки, этапы и ремонтные задачи с их статусами, порядком и агрегатами по списку.

Ресурсы и склад

Складской справочник расходников и их списание/возврат при привязке к задачам с контролем остатков.

Услуги

Привязка услуг из каталога к ремонтным задачам с тарифом, ценой и длительностью.

Стоимость и оплаты

Автоагрегация цены задачи из ресурсов и услуг и суммы оплат из платежей CRM, плюс статусы оплаты.

Метрика прибыли

Проецирование прибыли по ресурсам и услугам завершённой задачи в общую таблицу метрик.