Для уведомлений используется наше расширение «Сигнал».

Виды оповещений:

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

Виды событий, при которых возникает оповещение: при запуске задачи (или любого другого шага бизнес-процесса), при взятии задачи в работу, при выполнении задачи, при просрочке задачи.

Более подробно о подсистеме «Сигнал» можно узнать по ссылке Система автоматических оповещений.

Более подробно об интеграции с Telegram можно узнать по ссылке Интеграция с Telegram.

↑Наверх

Наш программный продукт подключается к любой конфигурации в режиме управляемого приложения.

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

Также, система может использоваться как отдельная конфигурация.

Подсистема работает как с типовыми справочниками/документами, так и с нетиповыми.

↑Наверх

Есть автоматический запуск процессов по событиям создания/записи элементов справочников/документов, запуск по расписанию, запуск по произвольным условиям, а также запуск по произвольным комбинациям трех предыдущих вариантов.

↑Наверх

Ручной запуск процессов предусмотрен. На основании объектов основной конфигурации или без основания.

↑Наверх

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

↑Наверх

Возможность остановки и отмены процессов предусмотрена.

Также, предусмотрена возможность остановки задач по процессам.

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

Также, доступны автоматические остановки и отмены процессов и задач по произвольным «триггерам».

↑Наверх

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

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

Ключевым понятием при использовании программного кода является «Алгоритм». Алгоритм является элементом справочника алгоритмов. Один и тот же алгоритм может использоваться множетсво раз в различных сценариях.

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

А чтобы вам было проще использовать возможности системы, мы позаботились о том, чтобы в системе была исчерпывающая информация об этим переменных и функциях.

Скриншот справки из системы: Переменные и функции

↑Наверх

Роли подсистемы предусматривают различные варианты разграничения доступа к объектам подсистемы.

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

↑Наверх

Такая возможность есть.

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

Доступны следующие варианты адресации:

• адресация задачи на 1 пользователя,

• адресация задачи на группу пользователей (при этом задачу для исполнения может взять любой пользователь группы),

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

↑Наверх

Такая возможность предусмотрена.

В описании задач возможно использование параметров вида [Параметр] и расчёт параметров с использованием произвольного программного кода.

Пример настройки доступен по ссылке Настройка параметров описания.

↑Наверх

Да.

Основа функционирования процессов — Сценарии.

Основа сценариев — Графические схемы.

Пример схемы доступен по ссылке: Пример графической схемы.

Подробнее о графических схемах можно узнать по ссылке Графические схемы.

↑Наверх

Предусмотрены различные варианты установки сроков выполнения задач:

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

Например такой: _Задача.ПлановаяДатаВыполнения = ДобавитьМесяц(_Процесс.Объект.Дата, 1), где в качестве объекта процесса может быть какой-то документ, по которому запущен процесс.

↑Наверх

Да.

Предусмотрен механизм хранения истории изменения статусов процессов и задач.

Для процессов и задач сохраняется вся история изменения статусов.

↑Наверх

Предусмотрен Отчёт по задачам с различными вариантами настроек.

Предусмотрена Диаграмма Ганта для отображения информации о задачах.

↑Наверх

Часть кода закрыта. Это часть, относящаяся к системе лицензирования и к «ядру системы» – механизмам функционирования логики процессов.

Настройку этой части системы, мы, пока, оставляем за собой.

Что касается прочих доработок, которые могут относиться к закрытой части и недоступной для клиента – здесь мы обсуждаем с клиентами их пожелания и, если какого-то необходимого функционала в системе нет (и нет способа адекватно обойтись существующим функционалом), то мы включаем его в очередные обновления. Конечно, если этот функционал вписывается в общую парадигму программного продукта.

Для примера можем привести описанный выше способ программного указания ↑срока выполнения задачи.

В текущей версии нет возможности явно указать при настройке сценария произвольный алгоритм расчёта срока задачи. Но, зная прочие варианты настроек, мы можем предложить клиенту указать алгоритм расчёта не на форме настройки срока выполнения задачи, а на форме настройки запуска, где он может указать алгоритм.

Таким образом, зная функционал, не требуется вносить в программу изменений.

Многие же предпочитают с ходу начинать вносить в программу изменения, считая, что быстрее и проще «допилить» всё самим, чем ждать, когда разработчик внесет изменения – знаем это, в том числе, и по собственному опыту разработок/внедрения и сопровождения программных продуктов.

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

Например, модуль формы задачи содержит стандартную процедуру ПриСозданииНаСервере(). В этой процедуре вызывается закрытая процедура бип_НаСервере.НастройкаФормыЗадачи(). В этой закрытой процедуре происходит первоначальная инициализация элементов формы задачи в соответствии с настройками сценария, к которому данная задача относится. Это видимость реквизитов, обязательность их заполнения, расположение и группировка реквизитов на форме, программная генерация таблицы данных и т.п. Эта процедура недоступна, т.к. включена в закрытый модуль. Но процедура, из которой она вызывается, доступна. И, при необходимости, клиент может переопределить настройки формы, которые были выполнены системой. Если, например, кому-то не понравится, что поле Комментарий расположено внизу формы, или кнопка Выполнена не того цвета, который хотят пользователи, то такие настройки программно доступны. Но не за счёт изменения штатной процедуры инициализации формы, а за счёт написания своего кода после штатной инициализации.

В качестве «лирического отступления» приведём небольшую цитату из книги Брюса Эккеля «Философия Java». В данном контексте нам, как кажется, эта цитата будет уместной.

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

↑Наверх

Переадресация предусмотрена.

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

↑Наверх

Предусмотрена.

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

↑Наверх

Предусмотрена роль «Наблюдатель».

Наблюдатель может добавляться вручную в существующей задаче, или определяться на стадии настройки сценария.

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

↑Наверх

Историю обновлений вы можете посмотреть на нашем сайте в разделе Описание изменений.

Динамика выхода обновлений зависит, в том числе, и от пожеланий клиентов.

Стоимость наших программных продуктов и дополнительных пользовательских лицензий доступна для ознакомления по ссылке: Прайс-лист.

Сроки предоставления технической поддержки и получения бесплатных обновлений: для основной поставки и при приобретении дополнительных лицензий – от 3 месяцев (см. прайс-лист).

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

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

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

В период технической поддержки вы обращаетесь со своими вопросами по электронной почте.

Мы стараемся отвечать максимально быстро, но, тем не менее, в общем случае, говорим, что срок рассмотрения вопросов может занимать до 3 рабочих дней. По факту – меньше.

↑Наверх

Никак. В режиме «Предприятие» отладка программного кода, написанного в алгоритмах, недоступна.

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

Например код _Результат = _Процесс.Объект.ОсновнойМенеджер. Или программный код с текстом запроса и выборкой результатов в цикле. В подобных случаях отладка и не требуется.

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

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

↑Наверх

Ограничений при настройках сценариев нет.

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

А инструмент не должен ограничивать тех, кто его использует.

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

История развития продукта доступна на нашем сайте по ссылке Описание изменений.

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

Наш программный продукт, как инструмент, предлагает вариативность в подходах к настройкам одного и того же сценария.

↑Наверх

Во всех версиях подсистемы: в конфигурации, в расширении, в базовой версии «Зодиак», обращения к внешним источникам/ресурсам отсутствуют.

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

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

По умолчанию, в подвале письма отображается логотип программы:

Но, так как шаблон подвала письма настраиваемый, вывод логотипа можно убрать в момент настройки параметров отправления оповещений.

↑Наверх

Да. Начиная с версии расширения для автоматических оповещений «Сигнал» 1.0.1.4.

Пример доступен по ссылке Пример выполнения задачи в Telegram.

Пример доступен по ссылке Пример выполнения задачи в Telegram.

Начиная с версии расширения для автоматических оповещений «Сигнал» 1.0.1.5, появилась возможность прикреплять видео-вложения.

Начиная с версии расширения для автоматических оповещений «Сигнал» 1.0.1.8, появилась возможность прикреплять аудио-вложения.

См. подробности в разделе Описание изменений.

↑Наверх

Да. Начиная с версии расширения для автоматических оповещений «Сигнал» 1.0.1.7.

Пример доступен по ссылке Вложения в Telegram.

↑Наверх

Да. Начиная с версии «КонструкторБизнесПроцессов» 1.0.4.0.

Приводим пример, как это может быть настроено в системе. Для упрощения примера опустим объект согласования (это может быть счёт, договор или любой другой объект системы).

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

В этой задаче согласовант должен отметить результат согласования: Да - Согласовано, Нет - Не согласовано.

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

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

Участник процесса выполнит необходимую для завершения задачи работу, укажет в задаче, при необходимости, комментарий и т.п. *В данном примере, это роли не играет.

При этом, на форме будут доступны 2 кнопки результатов согласования - Да и Нет.

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

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

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

И от этого будет зависеть дальнейший ход процесса.

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

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

Доступно 2 варианта: «Да», когда все «Да» и «Да», когда любое «Да».

В первом случае условие будет выполнено, только, когда все участники согласуют объект (т.е. нажмут «Да» в своих задачах).

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

Для нашего примера мы установим настройку «Да», когда все «Да». Т.е. все участники единогласно должны согласовать объект процесса.

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

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

*Это действительно только для тех задач, которые остальные участники ещё не выполнили и не взяли в работу.

В системе всё это будет выглядеть следующим образом:

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

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

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

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

Автоматически завершенные задачи в общем списке будут отмечены серой галочкой, а в самих задачах будет написано, что они былы завершены автоматически.

На карте процесса мы, также, увидим всю картину текущего процесса в динамике.

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

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

Автоматически завершенные задачи на карте процесса имеют отличия в оформлении (серая рамка + серая галочка).

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

↑Наверх

Неправильно выполнена подготовка расширения к использованию.

Инструкция по подготовке расширения «Мета-Бизнес-Процессы» к использованию доступна по ссылке:

Подготовка расширения «Мета-Бизнес-Процессы» к использованию.pdf

Видео с примером возможной ошибки и правильной настройки доступно по ссылке:

Настройка типов значений реквизитов в расширении «Новые Системы: Мета-Бизнес-Процессы»

Настройка типов значений реквизитов в расширении «Новые Системы: Мета-Бизнес-Процессы»

↑Наверх

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

В нескольких словах, общий порядок настройки следующий:

• настраиваем правила оповещений для сценариев,

• получаем уведомления о задачах (и их состояниях) в системе взаимодействия, по электронной почте или в Telegram,

• работаем с задачами - в программе, по электронной почте или в Telegram,

• получаем уведомления о результатах выполнениия задач в систему взаимодействия, по электронной почте или в Telegram.

Пример оповещений в Системе взаимодействия:

Видео с примером подобной настройки доступно по ссылке:

Система взаимодействия + Telegram

Система взаимодействия + Telegram

↑Наверх

Да.

Ключи лицензий можно использовать в нескольких базах. Это может быть актуально в следующих случаях:

• на предприятии используется несколько учетных баз,

• используется несколько баз разного назначения: тестовая база для настроек, проверок и т.п., рабочая учетная база для ведения учёта,

• ведётся разработка - есть база(ы) разработки, тестовая(ые) база(ы) и рабочая учетная база.

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

↑Наверх

Это штатное поведение типовых конфигураций и конфигураций, разработанных с использованием БСП («1С:Библиотека стандартных подсистем»).

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

↑Наверх

Да.

Начиная с версии «КонструкторБизнесПроцессов» 1.4.5, в подсистему включен интерактивный Планировщик задач.

Конструктор Бизнес-Процессов: Планировщик задач

Конструктор Бизнес-Процессов: Планировщик задач

↑Наверх

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

Вопрос о стабильности смещён в плоскость стабильности работы оборудования, сервера, платформы, сервера 1С, основной конфигурации.

А ответ на вопрос о выборе варианта интеграции мы оставляем за клиентами. Это зависит от требований к информационной системе, различных «индивидуальных» факторов, предпочтений. Именно поэтому мы и предлагаем в основной поставке 2 варианта, не ограничивая клиентов в выборе способа подключения.

↑Наверх

Лицензии требуются в целом для работы с подсистемой.

Лицензии - программные, бессрочные.

Под «работой с программой» подразумевается как создание/настройка сценариев бизнес-процессов, так и работа пользователей/исполнителей с задачами по бизнес-процессам.

Например, если у вас установлена основная поставка (она включает лицензии на 6 пользователей), то с подсистемой одновременно смогут работать 6 пользователей.

Что, при этом, они будут делать в программе – создавать/настраивать сценарии бизнес-процессов или работать с задачами по созданным ранее бизнес-процессам – это будет определяться уже настройками прав доступа пользователей.

Наличие или отсутствие лицензий не влияет на работу с основной конфигурацией

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

Дополнительная информация по лицензированию доступна по ссылке: Лицензирование.pdf [412 Кб]

↑Наверх

И да, и нет.

Если следовать точной терминологии, то можно говорить либо о ручной имитации процессов, либо об имитационном моделировании.

Для полноценной реализации автоматизированного имитационного моделирования (которое, потенциально, обладает бОльшими возможностями) потребуется значительный объём вводных данных о параметрах процессов. И это не только первичные данные из основной информационной системы (справочники, документы, регистры), но и «технические» параметры, необходимые для выполнения имитационного моделирования – например, различные вероятностные характеристики (сроков выполнения задач, вариантов условных переходов, выбора вариантов и т.п.) Т.е. на практике такой вариант подразумевает заполнение большого объёма «технических» данных, требуемых на входе. Причём, для каждого бизнес-процесса этот набор входных параметров будет индивидуален. И будет ли такой функционал востребован в рамках использования подсистемы в базах 1С, в настоящий момент (по состоянию на версию 1.4.6.26), уверенности нет.

Но в системе реализован механизм для проведения ручных имитаций.

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

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

↑Наверх

Да.

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

↑Наверх

Да.

Внешний вид формы задачи, состав реквизитов на форме задачи зависит от настроек текущей задачи в сценарии.

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

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

Например, в одной задаче пользователю требуется просто написать комментарий, в следующей требуется заполнить таблицу данных, в следующей ответить на вопрос Да/Нет и т.п. – для каждой задачи сценария поведение формы настраивается индивидуально и интерфейс задач будет отличаться – система динамически настраивает форму задачи в соответствии с настройками сценария.

↑Наверх

Подсистема встраивается в основную конфигурацию.

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

Работа с объектами основной конфигурацией и объектами подсистемы (сценариями, процессами, задачами) – в одном месте.

↑Наверх

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

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

↑Наверх

Да. Текст письма формируется в HTML-формате. Поэтому, в него можно добавить и произвольную таблицу.

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

Порядок настройки может быть следующим:

• Сначала в систему следует добавить алгоритм (назовем его СформироватьТаблицуДанных):
  

  Результатом выполнения алгоритма будет строка, содержащая HTML-код, формирующий таблицу данных по данным объекта, ссылка на который передана в Параметр1.

• Вызовем данный алгоритм при формировании текста письма в настройках оповещения подсистемы «Сигнал»:
  

• Теперь письмо будет приходить с таблицей данных:
  

• При необходимости, стандартными возможностями HTML можно добавить форматирование, настройки размеров, шрифты, цвет и т.д. Подвал письма отдельно настраивается в параметрах подсистемы.

↑Наверх