Здравствуйте.

Вопрос в следующем. Меняется процесс обработки обращений. Добавляются новые стадии и новые процессы по стадиям. Но при этом условия кейса остаются прежними. В системе имеется достаточное количество незавершенных обращений.

Версионности, как у бизнес-процессов, у кейсов нет. Как лучше ввести новый кейс, не сломав все открытые обращения? 

Нравится

7 комментариев

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

Здравствуйте, Алексей!

Предположим, в разделе настроена первая версия кейса (далее DCMv1) с определенным набором активностей для каждой стадии.
По записи в разделе был запущен кейс и созданы новые активности согласно DCMv1.
Далее кейс изменен на вторую версию (далее DCMv2) с другим набором активностей.
В результате активности, которые были созданы по DCMv1, отвязываются от кейса и становятся обычными задачами, которые привязаны к сущности. Если перейти на другую стадию и обратно – к обычным задачам добавляются еще новые активности, согласно новому кейсу DCMv2.
Это базовая логика приложения, сделанная для того, чтобы предотвратить потерю запланированных задач.

Александр Тыра,

Условие запуска кейса уже занято.

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

Здравствуйте, Алексей!

 

У Вас при смене кейса процессы отменяются или зависают? Стандартно запущенные  процесы по кейсу отменяются при смене стадии в кейсе.

У нас зависло много процессов в статусе выполняется. Причина - кейс перешел в состояние отменен и удалил за собой все данные по запущенным процессам. Процессы зависли в статусе выполняется. А вот почему кейс отменился ни я, ни техподдержка не выявили.  Единственное в тот день переносили обновления, в том числе и кейса. Но эта версия не подходит по времени. Разница в 7 часов. в 13 часов ставились обновления. Кейс отменился в 20 часов.

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

Показать все комментарии

Добрый день!

Подскажите, есть ли порядок в котором стартуют Бизнес-процессы в следующей ситуации (пример): 

Есть два БП. Один стартует по Сигналу от Объекта. Второй БП без стартового сигнала, но указан на одной из стадий динамического кейса объекта.

Допустим, что по условиям, оба БП должны отработать при переходе на стадию.

Оба запустятся одновременно или сначала отрабатывают БП на кейсе?

Нравится

1 комментарий

Оба запустится одновременно.

Показать все комментарии

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

В чем может быть проблема?

Нравится

5 комментариев

Может на проде в пакете Custom есть замещенный объект Лид и там стоит другое значение по умолчанию для стадии лида? Либо какой-то процесс, который меняет стадию. 

А как создаются данные лиды? Если приходят из Landing page, то ещё в конфигурации Landing page могут указываться значения по умолчанию, в том числе для стадий

Alex Zaslavsky,

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

Владимир Соколов,

Нет, создаются по процессу

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

Это может быть значение поля по умолчанию в дизайнере объекта «Лид» в одном из пакетов, в них же логика во встроенных БП на объекте «Лид», отдельные БП на событии создания или изменения лида, логика в событийном слое, триггер или значение по умолчанию в БД или, наконец, JS-логика на стороне карточки. Если создать тестовую запись на уровне ESQ (не сработает логика карточки) и на уровне Insert-запроса (сработает только логика БД), можно подтвердить или отсеять два последних варианта. Остальные нужно проверять, изучая все места вручную.

Показать все комментарии

Добрый день!

Имеется список кейсов (рис. cases.png), стадии которых определяются значением поля Stage, а тип кейса определяется значением поля Type. Кейс "Type = Legal customer acceptance v.2" не содержит процессов (рис. lca_case.png).

При сохранении записи с типом кейса "Type = Legal customer acceptance v.2" (как, впрочем, и с любым другим кейсом), создается и запускается процесс с именем "Type = Legal customer acceptance v.2" (рис. process_log.png). При попытке открыть этот процесс в дизайнере, выдается ошибка (рис. process_log_err.png). Если кейс деактивировать, создания процесса "Type = Legal customer acceptance v.2" не происходит.

Подскажите, пожалуйста, в чем проблема ?

Прикрепленные файлы

Нравится

3 комментария

Попробуйте посмотреть логи приложения, есть ли там больше информации по ошибке?

Вообще, записи в БД в таблице SysProcessLog по каждому экземпляру кейса — это нормально.

В журнале они могут отображаться или нет в зависимости от его настроек. См. SysProcessLogSectionV2:

addHideDcmFilter: function(filters) {
	var filterName = "HideDcm";
	filters.removeByKey(filterName);
	var shouldHideDcm = !Terrasoft.isDebug && !this.getIsFeatureEnabled("ShowDcmInProcessLog");
	if (shouldHideDcm) {
		var managerName = Terrasoft.manager.DcmSchemaManager.managerName;
		filters.add(filterName, Terrasoft.createColumnFilterWithParameter(
			Terrasoft.ComparisonType.NOT_EQUAL, "SysSchema.ManagerName", managerName));
	}
},

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

В новых версиях обещают полноценный журнал кейсов.

Зверев Александр,

спасибо за ответ! Да, режим отладки включен. 

Александр, корректно ли, что этот процесс находится в статусе Running?

 

Показать все комментарии

Добрый день, коллеги.

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

 

 

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

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

Нравится

1 комментарий
Лучший ответ

Добрый день.

Недавно подобная проблема обсуждалась в этом посте.

Добрый день.

Недавно подобная проблема обсуждалась в этом посте.

Показать все комментарии

Впервые хотел использовать этот элемент , и возможно некорректно настроил. 

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

Нравится

3 комментария
Лучший ответ

Кирилл Паксюдкин,

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

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

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

Посмотрите, обучающее видео про настройку прав доступа. Обратите внимание на приоритет прав доступа!

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

Проверьте соответствуют ли ваши записи указанным условиям отбора (фильтрации)

Шаг запускается под привелигированным пользователем? Если нет попробуйте выполнить под SuperVisor на тестовой записи

Григорий Чех,

фильтрация правильная, 

Шаг я запускал как от простого пользователя так и от Supervisor никакой блокировки нет.

Кирилл Паксюдкин,

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

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

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

Посмотрите, обучающее видео про настройку прав доступа. Обратите внимание на приоритет прав доступа!

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

Показать все комментарии

Всем доброго дня.

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

При переходе по статусам в старых записях на экран выдаётся сообщение об ошибке: "Процесс с идентификатором "<здесь разные guid'ы>" не найден".

Подскажите, пожалуйста, как можно эту ошибку исправить? Может очистить какую-либо таблицу?

Нравится

5 комментариев

Уже обсуждалось тут

Григорий Чех,

Смотрел в своё время ту тему. В журнале процессов пусто. Из кейса ничего не стартует - только ошибку выдаёт.

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

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

Фёдоров Александр Сергеевич,

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

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

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

По информации от разработчиков продукта, если элемент завершается с ошибкой из-за дедлока,  то может быть выполнен автоматический откат транзакции, поэтому и нет записей в таблице SysProcessElementData (дедлок был при попытке записи в таблицу). Такое поведение связано с ошибкой в движке процессов, которое исправлено в версии 7.11.

У Вас и так 7.11, попробуйте обновиться до последней 7.11.3 или ещё дальше.

Мотков Илья,

Очень похоже на описанное... Сейчас на 7.11.3. Будем планировать обновляться...

Показать все комментарии

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

Происходит отправка тестового сообщения по e-mail, но стадия после завершения процесса не меняется на "Ожидание". В чем может быть проблема?

Нравится

2 комментария
Лучший ответ

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

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

Егор Чесноков,  Спасибо, разницы нет никакой, но зато то что вы предложили работает.

Показать все комментарии

Здравствуйте, возникла проблема при создании подпроцесса в кейсе.

Суть такая, в подпроцессе (рис 1) считал данные по обращению и после этого хочу проверить заполнены ли полученные поля (рис 2), использую условный оператор, проверить id обращения получается (id != Guid.empty), но не понимаю как проверить остальные поля и дату с рисунка 2.

 

Нравится

2 комментария
Лучший ответ

Справочные поля можно также проверить, используя Guid.Empty. А дату можете сравнить с минимальной, например [#Читать данные 3.Первый элемент результирующей коллекции.Дата выполнения#] <= DateTime.MinValue. 

Справочные поля можно также проверить, используя Guid.Empty. А дату можете сравнить с минимальной, например [#Читать данные 3.Первый элемент результирующей коллекции.Дата выполнения#] <= DateTime.MinValue. 

Егор Чесноков, Благодарю, там ошибка скорее в построенной схеме объекта была, было два объекта с одним именем, и одно заполнялось, а второе нет, и про дату пригодилось)

Показать все комментарии

В начале сентября наша команда успешно завершила проект внедрения новой CRM системы в строительной компании «Интерстрой». Основной поставленной задачей была оптимизация работы отдела продаж и выход на новый уровень качества обслуживания клиентов.

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

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

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

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

Компания «ИнтерСтрой» получила новые точки роста, снижение издержек и повышение лояльности клиентов.

Подробности по ссылке на сайте 

Нравится

Поделиться

0 комментариев
Показать все комментарии