Добрый день!

 

Подскажите, пожалуйста, как удалить задачи, которые всплывают по умолчанию? Я захожу в "настроить кейсы раздела", но нигде не могу найти их. 

 

Изображение удалено.

Изображение удалено.

 

 

Нравится

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

Здравствуйте, возможно, что это готовая продажа в демо-версии, поэтому в настройке кейсов их нету, при этом на конкретной продаже отображаются.

Скажите, создав новую продажу всплывают ли аналогичные задачи при смене статуса? 

Pavlo Sokil,

При создании новой продажи задачи не появляются.

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

Приветствую всех.

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

Имеется такой вот вопрос: есть ли хороший способ, как можно, меняя на лету значение поля справочника, заставить менять как кейс, так и страницу раздела?

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

Но после первого сохранения записи выходит так, что при смене значения поля справочника, видно небольшое уведомление, мол имеется более подходящий кейс под новое значение справочника и его можно сменить https://prnt.sc/hTUiaTTn2qRe . Да, кейс поменяется, но страница при этом не меняется. Ну и менеджер банально может не нажать на кнопку смены кейса. А желательно бы, чтобы менеджер не мог работать с записью, пока не сменит кейс на соответствующий.

Интерфейс (страницу https://prnt.sc/oi79vQWQ-KMk ) удается сменить лишь проделав определенные манипуляции: меняем значение поля справочника, сохраняем, перезаходим в запись. Нужно именно перезайти в запись (закрыть и заново открыть), простое обновление страницы записи не помогает.

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

Заранее благодарен всем отозвавшимся.

Нравится

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

Добрый день!



Мне здесь отвечали на подобный вопрос: https://community.terrasoft.ua/questions/massovo-smenit-keys-dcm

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

 

Протестировали на коробочной версии Creatio и на данный момент это всё ещё коробочное поведение которое можно изменить только с помощью разработки.

 

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

Дополнительно, в посте https://community.terrasoft.ua/questions/zapustit-obnovlennyy-keys описана работа функции что отвечает за изменение кейса, возможно это поможет вам в разработке своего решения.

 

Спасибо вам.

 

Artem,

Спасибо за ответ, но пока не силен как разработчик, чтобы работать с функциями. Хотелось бы с помощью low-код как то сделать.

Но также вычленил одну фразу ответившего из поста https://community.terrasoft.ua/questions/massovo-smenit-keys-dcm

Там Ярослав поясняет:

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

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

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

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

Іван Щербатих пишет:

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

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

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

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

"Terrasoft.Common.DbOperationException: Конфликт инструкции INSERT с ограничением FOREIGN KEY "FKPU5pFJW1zR5qrqXfCC4TQdQNI". Конфликт произошел в базе данных "BPMonline", таблица "dbo.Pricelist", column 'Id'."

Подскажите, с чем может быть связана эта ошибка.

Спасибо!

Нравится

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

Ошибка значит, что в поле Pricelist некоего продукта был записан Id, которого не существует в таблице прайс-листов. Наиболее частая ситуация: попадание в поле значения пустого Guid {00000000-0000-0000-0000-000000000000}.

 

Исходя из того, что вы переносите продукты из продажи в заказ, скорее всего произошёл такой сценарий: 

- у какого-то копируемого продукта не был проставлен прайс-лист;

- в результат выборки соответственно пришло значение {00000000-0000-0000-0000-000000000000};

- при создании нового продукта устанавливается полученное значение пустого Guid;

- при попытке сохранить запись возникает ошибка.

 

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

Ошибка значит, что в поле Pricelist некоего продукта был записан Id, которого не существует в таблице прайс-листов. Наиболее частая ситуация: попадание в поле значения пустого Guid {00000000-0000-0000-0000-000000000000}.

 

Исходя из того, что вы переносите продукты из продажи в заказ, скорее всего произошёл такой сценарий: 

- у какого-то копируемого продукта не был проставлен прайс-лист;

- в результат выборки соответственно пришло значение {00000000-0000-0000-0000-000000000000};

- при создании нового продукта устанавливается полученное значение пустого Guid;

- при попытке сохранить запись возникает ошибка.

 

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

Vyacheslav Lipatkin,

Спасибо, разобрался. В поле была установлена константа (id теперь уже несуществующего объекта).

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

Добрый день!



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

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



В итоге привязка первой продажи к лиду пропадает.

Ваше мнение, как корректнее было бы управлять такими ситуациями?

Изображение удалено.

Нравится

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

Я бы предложила при возврате лида - оставить его для истории. А для работы создать новый лид . Ведь если лид не закончился продажей - значит необходимо поменять условия и тактику. Это уже можно назвать новым лидом. Возможно создать "Родительский лид" и связать его со всеми дочерними.

Так можно решить проблему и цитата: "...И в рамках одной потребности можем получать лиды на 10 вебинаров, 5 white page и по другим каналам  Причём, от разных контактов..." Привяжите их к "родителю". для "родительского лида" создайте отчетные поля.

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

О лидах и продажах описано тут.

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

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

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

Можно настроить в разделе фильтрацию, чтобы не видеть не интересующие лиды.

У меня больше идеологические расхождения. 

Что мы взращиваем - потребность (может быть много разных лидов) или конкретную заявку (лид в системе) 

И в рамках одной потребности можем получать лиды на 10 вебинаров, 5 white page и по другим каналам  Причём, от разных контактов.

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

Лидов может быть ещё больше. Если подключена веб-форма регистрации лидов, один и тот же человек может их завести сколько угодно. Но в результате продадут только по одному.

Я бы предложила при возврате лида - оставить его для истории. А для работы создать новый лид . Ведь если лид не закончился продажей - значит необходимо поменять условия и тактику. Это уже можно назвать новым лидом. Возможно создать "Родительский лид" и связать его со всеми дочерними.

Так можно решить проблему и цитата: "...И в рамках одной потребности можем получать лиды на 10 вебинаров, 5 white page и по другим каналам  Причём, от разных контактов..." Привяжите их к "родителю". для "родительского лида" создайте отчетные поля.

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

Есть такая задача:
У каждой стадии продажи есть максимальная длительность. Хочу на детали Стадии продажи видеть планируемую дату выхода из стадии на основании этой длительности + считать задержку относительно планируемой даты.
Может кто подскажите куда что надо прописать .поделится наработками.
Используем bpmonline 7-x.

Нравится

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

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

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

Можно ли реализовать периодический запуск БП?

"Кулак Олег" написал:Можно ли реализовать периодический запуск БП?

Да. На форуме есть обсуждения. Например: http://www.community.terrasoft.ua/forum/topic/15055

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

BPM 7.3.0.745

При замещение объекта "Продукт в продаже" возникает ошибка:
Ошибка сохранения: Имя "OpportunityProductInterest" объекта "Продукт в продаже" превышает 22 символов

Error image

Возможно ли заместить этот объект?

Нравится

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

Добрый день, Тарас!
Можно снять ограничение на имя схемы. Для этого нужно изменить значение параметра maxEntitySchemaNameLength в файле web.config загрузчика, то есть в корневом каталоге сайта:

<general connectionStringName="db" securityEngineType="Terrasoft.DB.MSSql.MSSqlSecurityEngine, Terrasoft.DB.MSSql" executorType="Terrasoft.DB.MSSql.MSSqlExecutor, Terrasoft.DB.MSSql" engineType="Terrasoft.DB.MSSql.MSSqlEngine, Terrasoft.DB.MSSql" metaEngineType="Terrasoft.DB.MSSql.MSSqlMetaEngine, Terrasoft.DB.MSSql" metaScriptType="Terrasoft.DB.MSSql.MSSqlMetaScript, Terrasoft.DB.MSSql" typeConverterType="Terrasoft.DB.MSSql.MSSqlTypeConverter, Terrasoft.DB.MSSql" binaryPackageSize="1048576" currentSchemaName="dbo" enableSqlLog="false" useOrderNullsPosition="false" maxEntitySchemaNameLength=100/>

Спасибо за ответ!

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

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

Нравится

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

В ds_OpportunityScript есть функция SetDefaultDatasetValues. Возможно, это происходит там.

Чтобы отключить заполнение поля "Состояние", необходимо изменить функцию SetDefaultDatasetValues сервиса ds_OpportunityScript таким образом (закомментированный код):

function SetDefaultDatasetValues(Dataset) {   
	var Today = GetTodayDate();
	var StartDate = Today.getVarDate();
	var ActualCloseDate = AddDateDays(Today, 7).getVarDate();
	Dataset.DisableEvents();
	try {
		Dataset.ValAsDateTime('StartDate') = StartDate;
		Dataset.ValAsDateTime('ActualCloseDate') = ActualCloseDate;
		Dataset.Values('OwnerID') = Connector.CurrentUser.ContactID;
		var OpportunityDefs = GetOpportunityDefs();
		var StatusID = OpportunityDefs.StatusID;
		/*if (!IsEmptyGUID(StatusID)) {
			Dataset.Values('StatusID') = StatusID;
		}*/	
		var RatingID = OpportunityDefs.RatingID;
		if (!IsEmptyGUID(RatingID)) {
			Dataset.Values('RatingID') = RatingID;
		}
	} finally {
		Dataset.EnableEvents();
	}
	Dataset.Values('CurrencyID') = GetBasicCurrencyID(); 
}

Чтобы отключить заполнение поля "Тип", необходимо добавить в функцию wnd_OpportunityEditOnPrepare сервиса wnd_OpportunityEditScript строку кода:

function wnd_OpportunityEditOnPrepare(Window) {
	Initialize(Window);
	wnd_BaseDBEditOnPrepare(Window);
	var Dataset = BaseDBEdit.Dataset;
/* MODULE WORKFLOW */
	if (Dataset.State == dstInsert) {
//Добавить эту строку
		Dataset.Values('TypeID')= null;

Спасибо большое, задача решена.

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

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

Нравится

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

Добрый день!

Абсолютно аналогичным образом.
Создайте новый ActionMenuItem в wnd_OpportunityWorkspace.

Код-пример для обработки нового действия продаж Вы можете взять из функции amiRecalcAmountOnExecute скрипта scr_InvoiceWorkspace.

Сама логика пересчета реализована в функции RecalcAmount того же скрипта.

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

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

Есть продажа, на основании которой создан документ(в таблице документа указан ID продажи, на основании которой он создан). В карточке документа отображается стадия это продажи (создан запрос и датасет, который отображает стадию продажи, тип поля датасета "Поле справочника", источник - датасет Стадий, колонка - ID стадии из таблицы продажи).

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

Спасибо.

Нравится

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

Здравствуйте, Дмитрий!

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

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

Пример описан в соседней теме: http://www.community.terrasoft.ua/forum/topic/6516

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

Спасибо. Описанный способ знаю.
Поле добавлено как справочник

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

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

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

Для чего это нужно?
1. Хочется в этой же детали отобразить Продажи, в которых данный Контрагент является не только клиентом, но и Посредником (BrokerID в Продажах).
2. Создать дополнительные представления, которые будут отображаться только если грид используется на детали раздела Контрагенты, содержащих прямые продажи (CustomerID) и косвенные продажи (BrokerID).
Как это реализовать?

Нравится

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

При переходе на деталь [Продажи] раздела [Контрагенты] происходит вызов функции RefreshOpportunityDetail() сервиса scr_AccountsWorkspace, где включается фильтр продаж по контрагенту (фильтр под названием 'CustomerID'). Фильтр 'CustomerID' реализован в сервисе sq_Opportunity.

"Ozzy" написал:1. Хочется в этой же детали отобразить Продажи, в которых данный Контрагент является не только клиентом, но и Посредником (BrokerID в Продажах).

Для того, чтобы на детали [Продажи] раздела [Контрагенты] отображались продажи, в которых контрагент является не только клиентом, но и посредником, необходимо :
1. Создать в sq_Opportunity набор фильтров, например, под названием AccountID, объединенных логическим оператором OR. Создать параметр с таким же названием.
Набор фильтров будет состоять из двух фильтров сравнения:
Первый:
[tbl_Opportunity].[CustomerID] = Parameter :AccountID
Второй:
[tbl_Opportunity].[BrokerID] = Parameter :AccountID
2. В функции RefreshOpportunityDetail() сервиса scr_AccountsWorkspace изменить название включаемого фильтра:

RefreshDetailData(BaseWorkspace.GridDataset, 'ID', 
		AccountsWorkspace.OpportunityDataset, 'AccountID');

"Ozzy" написал:2. Создать дополнительные представления, которые будут отображаться только если грид используется на детали раздела Контрагенты, содержащих прямые продажи (CustomerID) и косвенные продажи (BrokerID).

Управлять видимостью представлений в окне wnd_OpportunitiesGridArea, в зависимости от родительского раздела, можно таким образом: в функции function wnd_BaseGridAreaOnPrepare(Window) сервиса wnd_OpportunitiesGridAreaScript прописать код

var ParentWindow = Self.ParentContainer.ParentWindow.Name; 
if (ParentWindow == 'wnd_AccountsWorkspace'){         
                   dgvName.IsVisible = true;
         }   else {
		 dgvName.IsVisible = false;} 

Наталия, спасибо, все заработало.
Но с представлениями есть небольшая проблемка: при переключении между записями реестра и представлениями детали данные могут отображаться по разному, то есть или фильтр вообще не применяется - отображаются все продажи или записи детали не отображаются вообще, пока не сменишь контрагента и не вернешься обратно.
Где еще в скриптах необходимо прописать обновление/применение фильтров?

PS. Для созданных представлений FilterSetCode заполнил в соответствии с названиями фильтров в sq_Opportunity.

А для события OnActiveViewChanged Вы установили обновление датасета?

Нет, а что туда прописать надо?

Да вроде RefreshDetailData должна решить вопрос. А после перехода на представление и обновление реестра данные выводятся корректно?

Базовый рефреш вызывается и так.

"Гакало Игорь Александрович" написал:А после перехода на представление и обновление реестра данные выводятся корректно?
Нет, данные выводятся некорректно. Отследил монитором и вижу, что условия выборки накладываются как угодно или вообще не накладываются при переходах между записями реестра и переключении представлений.

Кажется мне, что FilterSetCode как-то не совсем так накладывается и необходима "ручная" установка фильтров.

Посмотрите на реализацию детали "Продукты в счете" в разделе "Проекты". Она должна помочь.

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