Работа с механизмом изменения статусов в БИТ.ФИНАНС

В системе БИТ.ФИНАНС реализована возможность настройки пользовательских алгоритмов изменения статусов объектов. Их внедрение необходимо в том случае, когда встроенного механизма изменения статусов не достаточно, либо необходима более тонкая настройка.
В данной статье будут рассмотрены основные моменты создания произвольного пользовательского алгоритма изменения статусов на примере документа "Заявка на расходование ДС", а так же ряд практических кейсов, связанных с изменением статусов объектов.

Оглавление:

• Начало работы
• Создание алгоритма
• Основные кейсы:
  • Необходимо чтобы заявки по ЦФО на суммы меньше 10 000 рублей сразу же переходили в статус "Утвержден" без дополнительного согласования
  • Необходимо чтобы документы меняли свой статус в процессе визирования в соответствии с тем, какая виза доступна
  • Необходимо полностью отказаться от согласования для объекта системы

В первую очередь, перед созданием пользовательского алгоритма изменения статусов, необходимо разобраться какие статусы и в каких случаях могут быть установлены для документа в системе.
Информацию о возможных статусах можно найти в разделе "Управление процессами (БИТ)" -> справочник "Статусы объектов".

Глобально статусы можно разделить на три группы:

1. Предопределенные статусы общие для всех объектов системы
2. Предопределенные статусы индивидуальные для каждого объекта системы
3. Пользовательские статусы

На данном этапе нас интересуют два первых пункта. Предопределенные статусы общие для всех объектов системы находятся в папке "Общие статусы объектов":

Индивидуальные же статусы находятся в папке с наименованием искомого объекта системы. В случае заявки на расходование денежных средств - это, соответственно, папка "Статусы заявки на расходование средств":

Общие статусы объектов присваиваются документу в следующих ситуациях:

1. Статус "Черновик" - документ записан.
2. Статус "На согласовании" - документ проведен.
3. Статус "Утвержден" - по документу установлены согласующие решения по всем доступным визам. При этом в алгоритме визирования должна быть хотя бы одна виза. Если алгоритм пустой, то статус не присваивается.
4. Статус "Отклонен" - хотя бы по одной визе принято отклоняющее решение.
5. Статус "Закрыт" - документ был закрыт при помощи "Закрытия документов планирования".
6. Статус 'Неопределен" - является техническим, присваивается только типовым документам.
7. Статус "Рабочий" - присваивается после проведения документам БИТ.ФИНАНС, для которых отключено визирование в регистре сведений "Управление объектами визирования".

Что касается индивидуальных предопределенных статусов, то ситуации в которых они устанавливаются у документа определяются эмпирически. В случае с Заявкой на расходование ДС они следующие:

1. Статус "Оплачен" - заявка была полностью оплачена или была переплата.
2. Статус "Частично оплачен" - заявка была оплачена частично.
3. Статус "В реестре" - заявка была добавлена в реестр платежей.

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

1. "Черновик"
2. "На согласовании"
3. "Утвержден"
4. "Отклонен"
5. "Закрыт"
6. "В реестре"
7. "Частично оплачена"
8. "Оплачена"
9. Пользовательские статусы

Так же заявка опционально может принимать статус "Рабочий", но взаимодействие с данным статусом будет более подробно рассмотрено при разборе практических кейсов.

После того, как был определен полный список статусов объекта и ситуации в которых они присваиваются можно перейти к непосредственному созданию алгоритма.
Алгоритмы изменения статусов создаются в разделе "Управление процессами (БИТ)" -> справочник "Алгоритмы процессов".

Алгоритм создается в виде блок-схемы, которая состоит из точки старта, точек действия, условия и завершения. Так же, в зависимости от закладываемой логики, могут быть добавлены точки слияния и разделения.

В точках действия прописываются статусы, которые будут назначены объекту системы, а в точках условия - пользовательские условия на переход к следующему статусу. Иными словами, именно от точек условия зависит переход от одного статуса к другому.

Рассмотрим на практике создание пользовательского алгоритма изменения статусов заявки, который будет работать идентично встроенному механизму:

1. Создадим новый алгоритм в справочнике "Алгоритмы процессов". По умолчанию по нажатию кнопки "Создать" открывается форма создания алгоритма визирования с пустым наименованием и тремя точками: "Старта", "Действия" и "Завершения".
Точка действия при этом создается не заполненной.

В первую очередь необходимо заполнить наименование и изменить вид алгоритма с "Визирование" на "Изменение статусов объектов".

2. Так как взаимодействие с заявкой в системе начинается с ее записи, то первым статусом заявки является "Черновик". Добавим его в алгоритм.
Для этого необходимо выбрать точку действия и в правой части формы нажать на кнопку "Создать".

В появившемся окне необходимо выбрать нужный статус (при этом наименование заполниться автоматически) и нажать кнопку "Записать и закрыть".

Первая точка заполнена.

3. Следующим статусом заявки является статус "На согласовании". Однако, сначала нужно добавить условие на переход к данному статусу, то есть необходимо добавить точку условия.
Для этого требуется нажать кнопку "Вставка" и выбрать пункт "Точка условия", после чего разместить ее на схеме. К данной точке необходимо подвести соединительную линию от первой точки действия.

Точка добавлена, но пока не заполнена. Для того чтобы ее заполнить, также выбираем в правой части формы команду "Создать". При этом откроется форма создания пользовательского условия. В пользовательском условии сначала заполняем наименование, контекст и объект системы.

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

В окне конструктора произвольного условия нам необходимо раскрыть пункт "Текущий объект" и найти реквизит "Проведен". Выбираем данный реквизит и в нижней части окна меняем значение на "Да". Сохраняем получившийся результат.

Теперь условие на переход к точке "На согласование" выглядит так:

4. Добавляем новую точку действия и прописываем в ней статус "На согласовании". При этом в точку приходит путь "Да" из вышестоящей точки условия. В свою очередь, путь "Нет" идет к точке завершения.

5. На следующей шаге необходимо добавить проверку не были ли приняты в процессе согласования отклоняющие решения. Для этого добавим точку условия "Отклонен?", где по пути "Да" алгоритм перейдет в точку со статусом "Отклонен", а по пути "Нет" продолжит свое выполнение.

При этом пользовательское условие будет следующим:

Важно, что в данном случае "Контекст" заполняется как "Текущий объект & Установленные визы".
Это позволяет выбрать в конструкторе произвольного условия следующие функции:

1. ВсеВизыПолучены - возвращает "Да", если по всем визам принято согласующее решение.
2. ПринятоРешение - возвращает "Да", если хотя бы по одной визе принято заданное в условии решение.
3. ПринятоРешениеПоВизе - возвращает "Да", если хотя бы по одной визе, указанной в условии, было принято соответствующее решение.
4. ПринятыРешенияПоВышестоящимВизам - возвращает "Да", если по вышестоящей в алгоритме визирования визе было принято любое решение.
5. ПринятоРешениеПоВышестоящимВизам - возвращает "Да", если по вышестоящей в алгоритме визирования визе было принято конкретное решение.

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

6. Добавляем условие на проверку утверждена ли заявка и точку действия со статусом "Утверждена".

При этом пользовательское условие будет следующим:

7. После того, как заявку утвердили она может быть добавлена в реестр. В этом случае ее статус измениться на "В реестре". Добавляем точку условия на проверку и точку действия.

При этом пользовательское условие будет следующим:

В конструкторе произвольного условия функцию "ВключенаВРеестр" можно найти в разделе "Прочее".

8. После согласования заявки и/или включения ее в реестр она может быть оплачена. При этом возможна как частичная оплата, так и оплата полностью. Добавим сначала проверку на частичную оплату и точку действия с данным статусом.

При этом пользовательское условие будет следующим:

В конструкторе произвольного условия функцию "СуммаОплата" можно найти в разделе "ОплатаЗаявки".

9. Финальный статус заявки - "Оплачена". Добавим проверку и точку действия. Важно так же не забыть добавить финальную точку завершения после последнего статуса, иначе система не позволит сохранить алгоритм.

Пользовательское условие следующее:

В данном случае мы устанавливаем в правой части строки условия флаг "Это выражение". Он позволяет нам сравнивать между собой функции и реквизиты объекта системы. В данном случае сравниваются функции "СуммаОплата" и "СуммаПлан", где первая - фактически оплаченная по заявке сумма, а второе - плановая сумма из заявки.
В итоге алгоритм выглядит так:

10. Помимо выше упомянутых статусов заявка так же может принимать статус "Закрыт". Однако, при помощи пользовательских условий задать переход к данному статусу нельзя. Поэтому в системе реализован механизм, устанавливающий данный статус вне зависимости от того используется встроенный или пользовательский механизм изменения статусов.

11. Записываем получившийся алгоритм. Он полностью повторяет встроенный в систему механизм изменения статусов. Для того, чтобы алгоритм начал работать, необходимо зайти в раздел "Управление процессами (БИТ)" -> регистр "Назначение алгоритмов" и назначить данный алгоритм объекту системы.

Важно помнить, что в отличии от алгоритмов визирования может быть назначен только один алгоритм изменения статусов.

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

Первый кейс.
Предположим, необходимо чтобы заявки по ЦФО "Администрация" на суммы меньше 10 000 рублей сразу же переходили в статус "Утвержден" без дополнительного согласования.
В этом случае нам необходимо модифицировать выше описанный алгоритм следующим образом:

1. После точки условия "Проведен?" добавляем точку условия "Согласование не требуется?".

Соединяем данную точку по пути "Нет" с точкой "На согласовании", а по пути "Да" добавляем точку слияния перед точкой "Утвержден" и присоединяем линию к точке слияния.

Само пользовательское условие при этом будет таким:

2. Модификация алгоритма завершена, однако этого не достаточно. Для того, чтобы в системе не "висели" доступные к установке визы по документам, которым визирование не требуется, необходимо создать пустой алгоритм визирования и назначить его заявкам.

Алгоритм должен состоять только из двух точек: "Старта" и "Завершения". В ином случае система не позволит его сохранить.

При этом регистр "Назначение алгоритмов будет выглядеть так:

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

Пусть, у нас для заявок назначен следующий алгоритм визирования:

Необходимо, чтобы, когда была доступна виза "Руководитель ЦФО" статус заявки был "На согласовании у рук. ЦФО", а при доступности визы "Казначей" статус был "На согласовании у Казначея".
Для этого, в алгоритме изменения статусов заменим пользовательское действие в точке "На согласовании" на новое пользовательское действие "На согласовании у рук. ЦФО".

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

После этого добавляем новую точку условия в которой будем проверять стала ли доступна виза "Казначей". В приведенном выше алгоритме визирования виза "Казначей" становится доступна сразу после установки решения по визе "Руководитель ЦФО". Соответственно, пользовательское условие будет следующим:

Осталось только добавить еще одну точку действия со статусом "На согласовании у Казначея" и записать алгоритм. На этом его модификация заканчивается.

Третий кейс
Необходимо полностью отказаться от согласования для объекта системы.

Это можно сделать двумя способами:

1. По аналогии с кейсом 1 настроить пользовательский алгоритм изменения статусов, где сразу после проведения будет осуществляться переход в статус "Утвержден".
2. Воспользоваться "Управлением объектами визирования". Данный регистр сведений находится в разделе "Управление процессами (БИТ)". При помощи двойного нажатия по строке можно включить или выключить визирование отдельного объекта системы в целом.