Где взять демо-версию вашей программы?

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

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

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

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

Если вы ещё не ознакомились с данными материалами, считаем, что они могут оказаться для вас полезными.

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

При необходимости мы можем организовать онлайн-презентацию.

↑Наверх

Как мы можем приобрести ваш программный продукт?

В большинстве случаев, по разовым сделкам мы выставляем по вашим реквизитам счет на оплату. В соответствии с действующим законодательством для подобных случаев его достаточно, т.к. он содержит все значимые условия сделки и может выступать в качестве договора. Оплата выставленного счета означает согласие с его условиями. Если вам, в соответствии с внутренними регламентами и другими требованиями, необходимы коммерческое предложение, лицензионный договор и/или другие документы, мы также их предоставляем. После оплаты счета, мы осуществляем электронную поставку программного продукта и дополнительных лицензий в срок до 2 рабочих дней с момента поступления оплаты. Комплектация зависит от приобретаемого программного обеспечения и дополнительных лицензий. См. Комплектация. Вместе со ссылками на дистрибутивы и ключами лицензий мы отправляем лицензионные соглашения и регистрационные карточки программного продукта. На этом передача прав на использование программного продукта в рамках установленных лицензионным соглашением пределов, завершается. Обмен документами осуществляется по каналам электронного документооборота. Скан-копии закрывающих документов, лицензионные соглашения и регистрационные карточки программного продукта и дополнительных лицензий отправляются в рамках переписки по электронной почте. Техническая поддержка осуществляется на условиях и в сроки, указанные в счете на оплату или в лицензионном договоре. Подробнее о технической поддержке см. Техническая поддержка. Обращаем ваше внимание, что согласно действующему законодательству программное обеспечение и дополнительные лицензии, а если точнее, неисключительные права на использование программного продукта, охраняемого законами об авторском праве, возврату и обмену не подлежат (ч.1, ч.4 ст.1259 ГК РФ, ч.1 ст.1235 ГК РФ, ч.1 ст.1286 ГК РФ). Информация об актуальных ценах на программный продукт и дополнительные пользовательские лицензии доступна по ссылке: Прайс-лист. Цена фиксированная? Как часто бывают у вас обновления? Какова процедура получения обновлений? С любыми вопросами вы можете обращаться на адрес mail@1bpm.ru. Мы будем рады вам помочь.

↑Наверх

Есть ли какие-то общие рекомендации по работе с подсистемой?

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

1. Подключать подсистему согласно инструкции.

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

   Каждый пункт инструкции важен.

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

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

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

3. Использовать справку на формах подсистемы.
4. Использовать доступную на сайте документацию.
5. Использовать видеоматериалы, доступные на нашем Youtube-канале.

6. Для «сложных» сценариев использовать вложенные процессы.

   Разбивать логику основного процесса на подпроцессы – это удобно.

   Настроенный для подпроцесса сценарий всегда можно использовать повторно в будущем в других сценариях. Это позволяет унифицировать процессы и упростить их эксплуатацию. «Divide et impera»

7. Упрощать схему, а не искусственно её усложнять.

   Хотя, упрощение само по себе – задача не всегда тривиальная, к этому следует стремиться. В том числе, используя рекомендации из пункта №6.

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

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

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

9. Делать сценарии рабочими.

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

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

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

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

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

   Если в вашем программном коде есть, например, деление на 0, процесс будет работать некорректно. Если деление на 0 возможно, это следует учитывать в самом программном коде, а не ждать, когда процесс «вдруг сломается».

   Неправильно: Цена = Сумма/Количество

   Более правильно: Цена = Сумма/?(Количество = 0, 1, Количество)

   См. рекомендации из пункта №8.

   Дополнительно см. FAQ28 – Ошибка в программном коде ( видео на Rutube)

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

    – Задавать понятные, конкретные, точные вопросы

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

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

    «Краткость – сестра таланта»

    «Правильно заданный вопрос содержит половину ответа»

    – Риторические вопросы или письма без вопросов могут остаться без ответа

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

Надеемся на ваше понимание.

↑Наверх

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

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

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

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

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

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

↑Наверх

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

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

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

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

↑Наверх

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

↑Наверх

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

↑Наверх

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

↑Наверх

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

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

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

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

↑Наверх

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

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

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

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

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

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

↑Наверх

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

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

↑Наверх

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

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

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

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

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

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

↑Наверх

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

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

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

↑Наверх

Да.

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

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

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

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

↑Наверх

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

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

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

↑Наверх

Да.

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

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

↑Наверх

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

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

↑Наверх

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

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

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

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

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

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

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

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

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

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

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

↑Наверх

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

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

↑Наверх

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

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

↑Наверх

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

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

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

↑Наверх

Цена фиксированная? Как часто бывают у вас обновления? Какова процедура получения обновлений?

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

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

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

Техническая поддержка предоставляется по электронной почте. В общем случае срок рассмотрения вопросов может занимать до 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 [319 Кб]

↑Наверх

И да, и нет.

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

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

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

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

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

↑Наверх

Да.

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

↑Наверх

Да.

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

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

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

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

↑Наверх

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

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

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

↑Наверх

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

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

↑Наверх

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

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

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

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

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

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

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

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

↑Наверх