Поиск

Личный кабинет

  1. Маршруты
  2. Документы
  3. Переход из одного БПФ в другой​
  4. ​Обучение настройки БПФ​
  5. БПФ несколько исполнителей на задаче​​​
  6. Оригинальные документы
  7. Схема настройки: BPF

1. Маршруты

Инструкция по настройке маршрутов в системе BSI
Основные понятия
Маршрут – это ряд определенных задач, выполняемых людьми и системами, которые направлены на достижение результата.
Точка – это блок, в котором  выполняется одна или несколько операций, обработка данных.
Соединение – определяет из какой точки возможен переход в другую точку.
Условие прохождение – после вычисления условия определяет, по какому маршруту пойдет выполнение задачи.
Роль – правило определения сотрудника, на которого будет назначена задача.
Настройка маршрутов подключена в меню Настройки для Генерации – Настройки – Маршруты.
  
Свойства маршрута

Для начала работы необходимо заполнить поля в заголовке настройки.
 
Рисунок 2 Внешний вид маршрута
Последовательность настройки маршрута:
1. Заполнение полей в заголовке
2. Заполнение полей на закладке «Общее»
3. Заполнение полей на закладке «Параметры»
4. Заполнение полей на закладке «Роли». После добавления ролей желательно сохранить маршрут, чтобы при настройке исполнителей в точках они отобразились.
5. Заполнение полей на закладке «Точки останова БП». Необходимо сохранить маршрут, чтобы точки появились при настройке переходов «Выход из точки».
6. Настройка переходов между точками. Рекомендуется у точек заполнять только «Выход из точки», тогда при сохранении маршрута автоматически будут проставлены ««Вход из точек», иначе возможны дублирования.

Заголовок
Маршрут движения БП* В данном поле указывается код бизнес-процесса
Название* В данном поле указывается наименование бизнес-процесса
Точки останова БП В поле указывается ссылка на таблицу состояний
Роли (закладка) Создаются роли для исполнителей задач, для каждого маршрута индивидуальный набор ролей.
Дополнительные уведомления (закладка) Схема хранит описание дополнительных уведомлений, во время прохождения его по бизнес процессу
Состояния (закладка) В поле указывается ссылка на таблицу состояний
Тип закрытия В поле указывается идентификатор доступа, используется администратором системы
Общее
Админ. процесса* В случае ошибок при прохождении маршрута, администратор получит уведомление.
Тестовый режим Значение по умолчанию = '0'. Если галочка установлена, то все почтовые уведомления будут отправляться администратору процесса. Рекомендуется использовать, если маршрут не настроен до конца.
Уведомлять В поле указывается, в каких случаях система должна рассылать уведомление исполнителю данного действия. Значение по умолчанию = '0'.
Возможные значения: 0:0-Только свое, 9:9-Все события
Точка отклонения В данном поле указывается код точки маршрута БП
Точка аннулирования В данном поле указывается код точки маршрута БП
Схема оригинального документа Указывается схема или ввод, которым запускается карточка документа
Схема сохранения для генерации роли Схема сохранения
Схема документа для WEB Схема, которая используется для документа на портале
Ставить визу один раз Если пользователю приходит несколько задач по одному документу, то достаточно подтвердить 1, остальные подтвердятся автоматически.
Таблица оригинального документа 

Свойства точки
Название элемента Назначение
Заголовок
Код В поле указывается внутренний код, генерируемый системой автоматически.
BPF В поле указывается код бизнес-процесса
Название точки БП В поле указывается наименование состояния бизнес-процесса
Тип точки В поле указывается метка, использовать основной ввод Значение по умолчанию = '20'.
Возможные значения: 1:1-Начальная, 20:20-Уведомление, 25:25-Виза, 30:30-Машинная процедура, 90:90-Завершение
Схема В поле указывается схема сохранения данных
Новое состояние В данном поле указывается код предыдущего состояния
Время выполнения Указывается время, когда должна начаться обработка выхода из точки для машинных точек.
SQL определения Время выполнения Указывается SQL скрипт для определения времени когда запускать машинную точку, В скрипте можно использовать переменную @DocID.
Достаточно любой визы? Если установлено, то документ при вхоже в точку будет требовать наличия хоть одной из входящих виз. По умолчанию требуется получение всех входящих виз. (0 -'И' 1 = 'ИЛИ') - вход по 'И' или по 'ИЛИ' Значение по умолчанию = '0'.
Автомат. НЕ пропускать Если установлено автоматически пропускать визу если человек ее уже установил (visa_one в BPF), то при установки этой галочки, данный поинт является действием и его пропускать нельзя Значение по умолчанию = '0'.
Глагол для темы Глагол который пишется для точки в задаче, чтобы поменять слово Утвердить документ
Не отсылать станд. увед. Значение по умолчанию = '0'.
Действия (закладка) Указывается перечень хранимых процедур, которые будут выполнены при прохождении этой точки.
Исполнители задач БП (закладка) Указываются исполнители. Возможно делегирование на другую роль по истечению указанного времени.
Дополнительные уведомления Схема хранит описание дополнительных уведомлений, во время прохождения его по бизнес процессу
Условие авто прохождения
Условие авто прохождения Если прописанное условие выполняется, то точка проходит автоматически без выполнения действий.
Кнопки (настройка доступных действий из точки)
Кнопка ВИЗА Значение по умолчанию = '1'.
Кнопка Отклонить Значение по умолчанию = '1'.
Кнопка Вернуть по маршруту Значение по умолчанию = '1'.
Кнопка Запросить визу Значение по умолчанию = '1'.
Кнопка Делегировать Значение по умолчанию = '1'.
Вход из точек
Указываются точки, из которых пришла задача в текущую точку. Заполняются автоматически при сохранении карточки из закладки «Выход в точки»
Выход в точки
Указываются точки, в которые уйдет задача из текущей точки. Есть возможность указания условия перехода.

2. Документы

3. 
Переход из одного БПФ в другой​

Данный режим создан ​для возможности из одного БПФ перевести документ в другой.Также можно, с помощью данного режима,сделатьизодногосложногоБПФ несколькопростых. 
Для того, чтобы настроить такую возможность, необходимо в "Точке выхода" стартового БПФ указать последующий БПФ. При этом задачи из предыдущего документа останутся и добавятся новые из нового БПФ. Все задачи из стартового документа должны быть завершены - в обратном случае появится ошибка. 
Также из одного исходного БПФ нельзя создать одновременно несколько (переход может быть только один).
Для работы данного режима все БПФ (и стартовый и производный) должны быть на одной оригинальной таблице (напр. если первоначальный на ic_header то и другой на ic_header​).

4. Обучение настройки БПФ​

​​Теория

Что такое маршруты и в чем разница между БП и БПФ

  • Последовательный бизнес-процесс (конечный автомат) - действия выполняются одно за другим от точки входа до точки выхода;
  • Бизнес-процесс со статусами (машина состояний) - имеет начальный статус, в процессе работы происходит переход из одного состояния в другое, может быть завершен в любой точке.

Преимущества БПФ

  • Асинхронность
  • Много поточность (сразу много задач могут быть подтверждены одновременно)
  • Автоматическое отклонение
Техническая информация для лабораторной:

Пользователь Windows: Konf пароль: Konf2013
Пользователи и пароли: в файле C:\BSI\BPF\Login.txt
Путь с схемам: C:\BSI\BSS

Лабораторная № 1 (время 60 мин) -  Создание нового БПФ и подключение схем к нему

Задача – Сделать простой Бизнес процесс Заявки на покупку валюты без подтверждений

Создаем схему в БСИ и таблицу - Заявка покупки валюты BSSOrderUSD

Поля

                - Code – первичный ключ, TIdentitySchema
                - Employee - Заявитель –обязательное -  ссылка на RefBook="STEmployeeBook"  Rule="(gRoot.GetEmployeeByLogin(gRoot.User)('Code')),();New"
                - Amount - Сумма –обязательное
                - DateOrder – Дата –обязательное

Сохраняем в файле C:\BSI\BSS\Settings\Schemas\BSSOrderUSD.xml
Подключаем схему в ClientsFile.xml
Создать таблицу в базе данных bss_order_usd, со всеми полями, (Можно командой RunScript InstallSchema(BSSOrderUSD))
Проверяем схему командой RunDict BSSOrderUSD – она должна запускаться, и создаваться записи

Создаем новый БПФ

Запускаем команду RunDict BPF
Создаем новый БПФ, кодируем его по своему усмотрению
Код БПФ присваиваем равным «111» Называем его «Заявка на покупку USD». Заполняем поля «Схема оригинального документа» и «Схема сохранения для генерации полей» значением нашей схемы – BSSOrderUSD.  Админ процесса «030 - Петров П. П.»

Примечание: «Схема оригинального документа» - используется при открытии документа по БПФ из почты или из задачи. «Схема сохранения для генерации полей» - используется для генерации ролей (см. Лабораторную №2)

Создаем новые три точки

11101 - «Стартовая» - тип точки «Начальная», «Новое состояние» «10 - Новый документ»
11120 - «Конечная» - тип точки «Завершение», состояние «30 – Удовлетворенная заявка»
11199 - «Аннулирования» - тип точки «Завершение», состояние «90 – Аннулировано»

Сохраняем наш БПФ

Открываем снова наш БПФ и на закладке «Параметры» в поле «Точка отклонения» указываем нашу точку 11199 - «Аннулирования». Теперь при аннулировании документ будет уходить в эту точку.

Открываем стартовую точку на редактирование и в Закладке «Выход в точки» создаем новую запись. В качестве точки входа указываем 11120 - «Конечная». Таким образом мы сделали выход из стартовой точки сразу в точку завершения. Сохраняем наш БПФ

Включить на таблице возможность запуска БПФ (http://bsip.org.ua/BS/BSI/Doc/Wiki%20Pages/%D0%97%D0%B0%D0%BF%D1%83%D1%81%D0%BA%20%D0%91%D0%9F%D0%A4%20%D0%BD%D0%B0%20%D0%BD%D0%BE%D0%B2%D0%BE%D0%B9%20%D1%82%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D0%B5.aspx)

В оригинальной таблице добавить два поля document и start_point_bpf
Поле «document (int)» должно быть вторичным ключем на таблицу fc_document
Поле «start_point_bpf (int)» хранит код начальной точки с которой будет стартовать БПФ. На оригинальную таблицу сделать триггер, который стартует БПФ.
Выполнив скрипт из файла Lab1.sql (также этот скрипт добавит поля для UpdateData)

Влючения на схеме всех возможностей БПФ

Cделать схему наследуемую от ParentSchema="BPF_BaseDoc". В схеме добавляем поле <element name="StartPointBPF" NullValue="11101"/>, для этого поля мы только определяем стартовое значение, само поле определено в схеме-родителе BPF_BaseDoc.

Примечание: Обязательно нужно переопределить NullValue для поля StartPointBPF, так как это основной признак говорящий базе что нужно запустить нужный нам БПФ

В схему добавим вычисляемое поле «Статуса» который будет нам говорить в каком состоянии находится наш документ.

<element name="StateInfo" type="string" size="300" FieldName=" docflow.fGetInformationPointEmplByDoc(~Document~)" Title="Этап визирования" ReadOnly="True" Update="False" VisibleInNewCard="False"/>

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

Схема должна получится аналогично той которая указана в файле Lab1.xml.

Проверяем наш БПФ

Открываем нашу схему RunDict BSSOrderUSD
Заводим новую карточку и сохраняем.
Открываем сохранённую строку и в закладке «Задачи» у нас должно быть две выполненных задачи. Для стартовой точки и точки завершения.
Также в поле состояние данной записи должно быть написано «Удовлетворенная заявка»

Лабораторная № 2 (время 60 мин) -  Добавление подтверждающих

Задача

-- Настроить роли в БПФ, Роль создатель заявки и роль главного бухгалтера.

- Добавить новые точки прохождения «Создатель заявки» и «Глав. Бух.» , и настроить их подтверждение, указать время на подтверждения для сотрудников.

-- Научиться пользоваться полем «Условие авто прохождения» - Решив задачу убрать создателя заявки для первого подтверждения,

- Теоритическая информация о поле «Ставить визу один раз».

Настроить роли в БПФ

Открываем наш БПФ на редактирование. В поле «Схема сохранения для генерации полей» указываем нашу схему, по которой будут рассчитываться роли «BSSOrderUSD». Заходим на закладку «Роли». И добавляем две новые записи.

Примечание: в поле «Формула», в Роли, пишется тильда выражение, по которому будет возвращен код СОТРУДНИКА для данной роли, относительно схемы указанной в поле БПФ «Схема для генерации роли». Одна роль может возвратить только одного сотрудника.

111Creator – «Инициатор» - В поле формула указывается «dbo.GetEmployeeByLogin(~UpdateData/CreateID~)»
111Acc – «Бухгалтер» - В поле формула указываем сразу код сотрудника в одинарных кавычках «'022'»

Сохраняем наш БПФ

ПЕРЕГЕНЕРИРУЕМ РОЛИ: Запускаем команду БСИ «GenerateProcBPFRole»

Добавить новые точки

Открываем наш БПФ на редактирование. Заходим на закладку Точки. Добавляем две новые точки

11104 - «Акцепт инициатором» - тип точки «Виза», состояние «15 – На утверждении»
11108 - «Акцепт Глав.Бухом» - тип точки «Виза», состояние «15 – На утверждении»

Заходим в точку 11104 - «Акцепт инициатором», открываем закладку «Исполнители задач БП». Заводим нового исполнителя, в качестве кода роли указываем 111Creator – «Инициатор».

Заходим в точку 11108 - «Акцепт Глав.Бухом», открываем закладку «Исполнители задач БП». Заводим нового исполнителя, в качестве кода роли указываем 111Acc – «Бухгалтер».

Сохраняем наш БПФ

Открываем наш БПФ на редактирование. Заходим на закладку Точки. Открываем стартовую точку, на закладке «Выход в точки» удаляем связь между стартовой точкой и точкой завершения. И создаем новую запись соединяя стартовую точку с точкой 11104 - «Акцепт инициатором» .

Аналогично делаем для точки  11104 - «Акцепт инициатором», соединяем ее с точкой 11108 - «Акцепт Глав.Бухом». А точку 11108 - «Акцепт Глав.Бухом» соединяем с точкой 11120 - «Конечная». Таким образом мы получили линейное утверждение двух пользователей.

Проверка результата.

Открываем нашу схему RunDict BSSOrderUSD

Заводим новую карточку и сохраняем.

Открываем сохранённую строку и в закладке «Задачи» у нас должно быть одна выполненная задача для стартовой точки, активная задача для точки «Акцепт инициатором».

По правой клавиши мыши в гриде, либо в открытой карточке мы подтверждаем точку «Акцепт инициатором». У нас должна задача, которая была на точке «Акцепт инициатором» стать завершенной и должна создастся новая задача «Акцепт Глав.Бухом». Аналогично если мы подтвердим задачу на точке «Акцепт Глав.Бухом», у нас задача завершится и документ уедет в точку «Конечная».

«Условие авто прохождения»

Для того чтобы при старте документа инициатору не нужно было подтверждать документ. Но при этом оставалась возможность возвращать на точку «Акцепт инициатором», мы делаем условие автоматического прохождение точки если задача проходит первый раз. Для этого в поле «Условие авто прохождения» в точке «Акцепт инициатором». Мы указываем формулу

(select Count(*) from sy_bpf_task t with(nolock) where t.doc_id = @DocID and t.point = 11104) = 0

Примечание: В этом поле указывается не тильда выражении, а любое SQL выражение в котором можно использовать переменную @DocID

Проверка «Условие авто прохождения»

Открываем нашу схему RunDict BSSOrderUSD
Заводим новую карточку и сохраняем.

Открываем сохранённую строку и в закладке «Задачи» у нас должно быть две выполненнаые задачи для стартовой точки и для точки «Акцепт инициатором». И одна активная задача «Акцепт Глав.Бухом».

Поле «Ставить визу один раз» в БПФ

Данное поле служит для облегчение работы пользователей. Если в этом поле стоит галочка то если будет создана новая задача на пользователя который уже ставил визу в этом документе то эта задача будет подтверждена автоматически
Зайти в БПФ на редактирование и Поставить галочку на это поле.

Лабораторная № 3 (время 60 мин) -  Настроить параллельный процесс с руководителем отдела и бухгалтера, возможность условных переходов

Настроить параллельный процесс с руководителем отдела и бухгалтера, возможность условных переходов
Попробовать работу по «И» и «ИЛИ» на выходе из точки
Сделать условие по сумме если меньше 20 то руководитель подтверждает иначе глав. Бух.
Добавить точку КАССА в конце на бухгалтера и галочка «автоматически не пропускать»

Настроить параллельный процесс

Открываем наш БПФ на редактирование. Заходим на закладку Точки. Добавляем две новые точки
11105 - «Акцепт руководителем» - тип точки «Виза», состояние «15 – На утверждении», добавляем в качестве исполнителя роль 111Manager «Руководитель»– с формулой «'003'» (смотри прошлую Лабораторную)
11115 –«Касса» - тип точки «Виза», состояние «20 – Удовлетворенный» , в качестве исполнителя добавляем существующую роль 111Acc

Сохраняем наш БПФ

Открываем наш БПФ на редактирование. Заходим на закладку Точки. Открываем точку Акцепт инициатором, на закладке «Выход из точки» добавляем связь между стартовой Акцепт инициатором и Акцепт руководителем. То есть у нас ДВА выхода из точки Акцепт инициатором. На акцепт руководителем и на акцепт бухгалтером. При такой настройке эти точки создадутся параллельно и утверждать их тоже можно параллельно.

Далее для точки 11105 - «Акцепт руководителем» делаем выход на точку 11115 –«Касса»
И выход с точки 11108 - «Акцепт Глав.Бухом» меняем с точки завершения на вточку на точку 11115 –«Касса»

Проверяем работу по «И» и «ИЛИ» и Тестируем параллельное утверждение

Открываем нашу схему RunDict BSSOrderUSD
Заводим новую карточку и сохраняем.
Проходим действие «Акцепт инициатором», если оно не в «авто подтверждении».
У нас должно создастся две активных задачи Одна для Руководителя, вторая для Глав буха.

По правой клавише мыши в гриде подтверждаем задачу руководителя. После подтверждения задача бухгалтера останется активной и документ не уйдет в завершение. Это сценарий работы по «И». То есть для того чтобы попасть в точку 11115 – «Касса» куда ведут два входа и от руководителя и от глав.буха, нам нужно чтобы все параллельные задачи были подтверждены.

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

Теперь подтверждаем вторую точку. У нас документ должен зайти в точку 11115 – «Касса».

Чтобы поменять работу параллельных точек и сделать так чтобы при подтверждении одной из параллельных ветвей сразу процесс шел дальше. Необходимо в точке входа параллельных ветвей поставить галочку «Достаточно одной визы.» В нашем случае это нужно сделать в точке «Завершения». Маршрут поведет себя так. При подтверждении одной из точек процесс пойдет дальше и при этом вторая ветка будет АННУЛИРОВАНА.

Протестируйте.

Оставим маршрут по «ИЛИ» для следующего примера.

Условные переходы

Открываем наш БПФ на редактирование. Заходим на закладку Точки. Открываем точку Подтверждение Инициатора. На ней у нас два выхода. Открываем выход в точку акцепт руководителя. В поле «Условие перехода» записываем следующую формулу

«(select f.amount from bss_order_usd f with(nolock) where f.document = @DocId) < 20»
Примечание: В этом поле указывается не тильда выражении, а любое SQL выражение в котором можно использовать переменную @DocID
Открываем переход в точку акцепт ГлавБухом и ставим галочку «Идти по НЕ»
Тестируем наш условный переход. Если сумма при старте будет указана более 20 то пойдет по одному маршруту иначе по другому

Галочка в точке «автоматически не пропускать»

У нас в БПФ была установлена галочка «Ставить визу один раз». Поэтому при тестировании мы должны были автоматически проскакивать точку «Касса», если точку бухгалтера подтверждал пользователь Acc, так как исполнителем кассы является бухгалтер, который уже ставил свою визу. Но по идее в кассе нам нужно обязательно остановится чтобы выдать деньги. Для этого служит галочка в точке «автоматически не пропускать».

Установим данную галочку и протестируем маршрут.

Лабораторная № 4 (время 60 мин) -  Создание нового БПФ и подключение схем к нему

Задача создать проводки при подтверждении выдачи денег из кассы. И создать функцию отмены.
Рассмотреть все возможные варианты работы с задачами.

Функции работы с базой

В нашей задаче мы не будем создавать проводку, а просто сделаем новую запись в таблицу FC_COR. В качестве идентификатора в поле Description укажем наш код документа.

Для этого нам нужно создать SQL процедуру. Процедуры для точек всегда имеют три параметра

(@DocId integer, @Param varchar(max), @User varchar(20))

Где DocId – код документа, @sParam – поле настроеное в вызове проыедуры, @User – пользователь подтвердивший переход.

Создаем в SQL процедуру

ALTER PROCEDURE [dbo].[BSS_BPF_bss_order_usd_KASSA] (@DocId integer, @Param varchar(max), @User varchar(20))

AS

BEGIN

  insert into fc_cor (COR, Name, Description1, Description2, is_cor)

  values ('DOC' + CAST(@DocId as varchar), 'Тестовая ' + CAST(@DocId as varchar), @DocId, @Param, -1)

 END

 Данная процедура вставит новый COR.

Примечание: Обратите внимание на название процедуры, обязательно в качестве префикса имя клиента. Также в названии присутствует слово BPF которое говорит, что процедура для маршрута.

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

CREATE PROCEDURE [dbo].[BSS_BPF_bss_order_usd_UNDO_KASSA] (@DocId integer, @Param varchar(max), @User varchar(20))

AS

BEGIN

  delete from fc_cor where COR = 'DOC' + CAST(@DocId as varchar) and Description1 = @DocId

END

 Открываем наш БПФ на редактирование. Заходим на закладку Точки. Открываем точку Подтверждение Касса. Заходим на закладку «Действия» Добавляем новое действие

Код не указываем,

Название – «Проведение проводок»,

Хранимая процедура дейсвия - BSS_BPF_bss_order_usd_KASSA

Параметры процедуры дейсвия – любой текст который у нас попадет в поле Description2 в сгенерированный fc_cor

Хранимая процедура отката - BSS_BPF_bss_order_usd_UNDO_KASSA

Время выполнения – ставим «На выходе в транзакции», это поле указывает когда выполнять данную процедуру. При установленном значении «На выходе в транзакции» - процедура будет выполнена в момент подтверждения пользователем в той же транзакции что и подтверждение. То-есть пользователь будет ожидать результат и при ошибке он ее сразу увидит. Все остальные значения будут делаться асинхронно и пользователь не увидит произошла ошибка в выполнении или нет, при этом администратору будет отправлено сообщение об ошибки и администратор БПФ должен ее урегулировать

Тестируем Наш БПФ. Смотрим что запись в FC_COR создается

Возможные действия над задачами

Над задачами возможно делать только строго лимитированные действия. Эти действия зашиты в систему

Дейсвия которые можно производить над задачей:

- Подтвердить задачу

-- Делегировать задачу - когда пользователь переназначает свою задачу на другого

-- Запросить доп. Визу – по данной задаче будет запрошена новая СВЯЗАННАЯ задача. Все связанные не подтвержденные задачи аннулируются при подтверждении основной задачи.

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

-- возврат на доработку – Аннулируется текущая задача и Создается новая задача (не точка) на пользователя в чью точку вернули на доработку (аналог Динамических виз.)

-- Аннулирование – полное аннулирование документа. Все пройдённые точки аннулируются и документ попадает в точку указанную в БПФ как «Точка отклонения»

-- Отозвать визу – срабатывает аналогично возврату по маршруту. Данная функциональность доступна только на основном маршруте (не динамическом), и только если данную визу ставил тот, кто отзывает

Управлять этими возможностями можно в точке. Откройте точку на редактирование и зайдите на закладку «Кнопки», там можно установить видимость или отсутствие любой из возможностей.

Проверим на примере отката точки «Касса», убедится, что при откате наш сгенерированный COR удаляется.

Динамические визы теория (15 минут)

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

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

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

Все новые участники работают на подтверждение параллельно !!!

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

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

Настройка почты, Настройка доп. уведомлений –теория (15 мин)

RunDict BPFMsgCategory

Переход из одного БПФ в другой–теория (10 мин)

Данный режим создан для возможности из одного БПФ перевести документ в другой. Также можно, с помощью данного режима, сделать из одного сложного БПФ несколько простых.

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

Также из одного исходного БПФ нельзя создать одновременно несколько (переход может быть только один).

Для работы данного режима все БПФ (и стартовый, и производный) должны быть на одной оригинальной таблице (напр. если первоначальный на ic_header то и другой на ic_header).

Лабораторная № 5 (время 30 мин) Видимость в БПФ

Возможность настроить видимость и обязательность полей при прохождении той или иной точки

Для того чтобы в схеме сработала видимость необходимо в оригинальной схеме в заголовке указать OnVisible="OnShowBPF" BPFDocument="Document". Данные атрибуты у нас настроены через наследуемую схему.

Алгоритм работы следующий

Для каждого поля высчитывается коэффициент, если поле встречается дважды - то берется максимальная цифра.

Если поле помечено в точках:
  • -- активные точки на пользователе – 9 - Приоритет внутри 'N','S','R','H'
  • -- пройдённые точки данным пользователем - 7 (-- при этом меняем 'S'(видимое), 'N'(обязательное) и превращаем их в 'R' (только для чтения), для того чтобы те поля, которые он вносил были видны) - Приоритет внутри 'H','R'
  • -- активные точки других пользователей - 6 (- берем только поля 'H'(невидимое), 'R'(только для чтения)) - для того чтобы по максимуму скрыть поля- Приоритет внутри 'H','R'
  • -- финишная точки -6 (берем только 'H'(невидимое), 'R'(только для чтения), 'S'(видимое))- Приоритет внутри 'H','R','S'
Для группы администраторов работает как будто они находятся в активной точке.

Для понимания какие поля видит пользователь мы используем запрос 

select * from [dbo].[sy_GetFieldVisibilityByDoc_Prepare](@DocId,@Employee)

Настроить видимость на полях

Задача: создать два поля «Выдано из кассы», «Не редактируемое для кассы», настроить их видимости для кассы. Так чтобы «Выдано из кассы» - не было видно никому кроме кассы, «Не редактируемое для кассы» - было доступно на редактирование всем кроме кассы

Добавляем два новых поля в нашу схему

    <element name="ReadOnlyCash" type="string" size="300" Title="Не редактируемое для кассы" Update="False" />

    <element name="AmountCash" type="currency" size="0" FieldName="Amount_cash" GridVisible="False"    Visible="False" ReadOnly="True" Title="Выдано из кассы"/>

Перегружаем схему в БСИ. И сделаем RunScript InstallSchema(BSSOrderUSD), для того чтобы появились поля в базе.

Запускаем команду RunDict BPFVisibilitySetup. Открываем в реестре наш БПФ. Заходим на закладку «Видимость поле БП по точке». В открывшейсе матрице напротив поля ReadOnlyCash в столбце «Касса» ставим «R-только для чтения». Возле поля AmountCash в столбце «Касса» ставим «N-обязательное.

Проверяем поведение системы. Теперь поле «Не редактируемое для кассы» должно быть ReadOnly для кассы, а для остальных точек должно быть доступно для редактирования. Поле «Выдано из кассы» должно быть невидимое для всех точек кроме точки «Касса», при этом точку Касса невозможно подтвердить пока мы не заполним данное поле.

В БПФ есть возможность установить видимость на поля .
для установки видимости нужно 
запустить такие команды
ReloadSchema Schemas\SYSTEM\BPF_visibility.xml
RunDict BPFtest

Концепция настройки видимости в БПФ предполагает что в схеме будет максимально убрана видимость

а в настройке мы ее будем включать

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

OnVisible="OnShowBPF" BPFDocument="Document"

Сейчас работают доступы только на точки.

Алгоритм работы следующий

Для каждого поля высчитывается коэфицент, если поле встречается дважды - то берется максимальная цифра​.

Если поле помечено в

-- активыне точки на пользователе - 9 - Приоритет внутри 'N','S','R','H'​

-- пройденые точки данным пользователем - 7 (-- при этом меняем 'S'(видимое), 'N'(обязательное) и превращаем их в R(только для чтения), для того чтобы те поля которые он вносил были видны) - Приоритет внутри 'H','R'

-- активные точки других пользователей - 6 (- берем только поля 'H'(невидимое), 'R'(только для чтения)) - для того чтобы по максимуму скрыть поля- Приоритет внутри 'H','R'

-- финишная точки -6 ( берем только 'H'(невидимое), 'R'(только для чтения), 'S'(видимое))- Приоритет внутри 'H','R'​,'S'

Для группы администраторов работает как будто они находятся в активной точке. С подменой 'H'(невидимое) на  'R'(только для чтения)

Для понимания какие поля видит пользователь мы используем запрос 

select * from [dbo].[sy_GetFieldVisibilityByDoc_Prepare](145908,'2866')

Но возник вопрос тогда когда в схеме сделали поле Обязательным, а для некоторых точек его хотели спрятать. 

Для такого случая я внес изменения в схему видимости БПФ. И теперь если на поле в схеме стоит обязательное поле - то данная видимость копируется на все поля у которых указана видимость "Как в схеме"​

Лабораторная № 6 (время 60 мин) Авто подтверждения при окончании времени, Машинные точки

Авто подтверждения при окончании времени

Для критических точек, которые не должны зависать долго на пользователе, можно поставить галочку «Авто прохождение по окончанию времени», и если нужно что-то дополнительное сделать в базе то можно установить «Функцию при Авто проходе». Данная функция имеет следующие параметры

@TaskID int, @Params varchar(100)

Где @TaskID – код задачи которая будет подтверждена, @Params – параметры (сейчас не используются)

Задача будет автоматически подтверждена по окончании времени выделенного пользователем на исполнение задачи. И в комментарии будет написано 'Пользователь не выполнил задание в указанный срок. '

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

Проверить на точке утверждения Руководителя отдела, указав время исполнения 5 минут.

Машинные точки

Машинные точки — это те точки, которые подтверждаются автоматически.

Машинные точки используются в следующих случаях
  • Объединяющие – когда нужно свести маршрут в одну точку
  • Временная задержка (не раньше чем через 2 месяца – прием на работу или руками подтвердили)
  • Выполнение каких-либо процедур
  • Ожидание какого-то события– после кассы делаем точку ожидания проводки что деньги получил на примере изменения таблицы COR
Настроим пример ожидание события. Заведем новую точку 11118 «Ожидание покупки валюты». Данная точка будет находится между кассой и окончанием. Тип точки делаем машинная точка. Ожидать будем любого изменения в таблице fc_cor.

Для этого в этой точке мы должны установить в поле

(select MAX(t.CreateDate) from

sy_bpf_task t with(nolock) where t.doc_id = ~Document~

and t.point = 11118) < (select MAX(c.ChangeDate) from fc_cor c with(nolock))

Примечание: В данном поле пишеться условие в тильда выражении, относительно схемы указанной в поле «Схема для генерации роли»

Примечание: Ожидание события работает по шедулеру, сейчас частота запуска 10 мин.

Проверяем нашу точку.

5. БПФ несколько исполнителей на задаче​​​

Появилась возможность иметь нескольких исполнителей в одной задаче

Сделана возможность устанеавливать нескольких исполнителей на точке
Для этого в роли есть возможность задать формулу которая возвратит несколько Employee в одной строке разделенные "|" (вертикальной чертой)
Технически реализована еще одна таблица sy_bpf_task_add_executor в которой хранятся эти исполнители к задаче
Также при создании задачи в таблицу sy_bpf_task_add_executor помещаются все замы основного исполнителя
При этом у администратора есть возможность в эту таблицу вносить руками новых исполнителей для конкретной задачи. Для разделения того что внесли руками и того что сгенерировали автоматически в этой таблице есть поле is_generated (при автоматической генерации оно заполняется 1)
В базе также есть процедра для пересчета этой таблицы - docflow.pCalcAddExecutor @Task  или docflow.pCalcAddExecutorAsinc @Task  или ​​​​​

При перегенерации ролей, при изменении состава заместителей у сотрудника, вызывается процедуры перегенерации sy_bpf_task_add_executor​

Перегенерация ролей осуществляется через команды
ReloadSchema System\BPF\GenBPFRoleScript.xml
RunScript GenBPFRole_GenerateProc​

6. Оригинальные документы

Оригинальные документы - это любые документы (бизнес объекты) которые содеденяются с документом 1-1
Чтобы сделать из таблицы возможность хождения по Маршрутам необходимо

1 В таблице завести два поля
document - ссылка на документ, с каскадным удалением
start_point_bpf - стартовое действие для докмента

2 На таблицу настроить тригер который будет создавать документ и сохранять ссылку на этот документ

Настроеные таблицы для маршрутов (поставляемые вместе с системой)

Deal - Договора и сделки

Сохраняет договора и сделки
имеет детали "Условия оплаты" "Спецификация"
Сумы и даты в деталях могу расчитыватся автоматичкски по зависимостям внесеные в справочник DealEventType

Требование к DealEventType

требование к полю [function] таблицы fc_deal_event_type
1 поле должно содержать запрос заключенный в скобки
2 Для суммы запрос должен возратить два поля сумму и валюту
3 для даты запрос должен возратить одно поле - Дату
4 для обращения к таблице fc_deal_rule которую будем делать UPDATE префикс пишем fc_deal_rule
напимер для обращения к коду fc_deal_rule.code
требование к полю trigger_body таблицы fc_deal_event_type
1 поле должно содержать только тело тригера без его определения
2 в UPDATE не должно быть SET и указании полей которые мы меняем, а нужно указать SET
тоесть в двойных квадратных скобках 
при генерации скрипта туда подставится все необходимые поля 
сумма или дата посчитаются по полю [function] таблицы fc_deal_event_type
также перед UPDATE в тригере необходимо проверить что есть записи которые мы будем апдейтить

Project - Проекты
Record - Записи

Документация