Есть карточка контрагента и наименование контрагента.
С карточкой работают сотрудники разных стран.
Кому-то нужно название на русском, кому-то на англ.

Как с точки зрения работы с мультиязычностью сделать так, чтобы при поиске по полю наименование в России искало по русскому названию, а в иноязычных странах – по английскому? (скрин во вложении) Изображение удалено.
Или как сюда для англоязычных пользователей автоматически подставить поле название Eng
Изображение удалено.
Что тоже могло бы помочь в решении проблемы

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

Нравится

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

Добрый день, 

К сожалению, не отображаются скриншоты в сообщении. 

 

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

 

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

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

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

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

В настройке фильтра доступны только объекты "Взаимосвязь (по колонке Контрагент А)" и "Взаимосвязь (по колонке Контрагент Б)", но насколько я понимаю, в 7.17 эти объекты уже не используются про добавлении связей на диаграмму взаимосвязей. Как правильно поступить?

Нравится

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

Добрый день!

 

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

В колонке RecordId таблицы RelationshipEntity нет связи ни с каким объектом, так как в этой колонке могут храниться как записи контакта, так и аккаунта.

 

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

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

Добрый день!

Подскажите, какими оптимально способами решать задачу, чтобы определенные пользователи видели и могли редактировать только Контрагентов с типом Клиент?

Спасибо!

Нравится

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

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

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

Нигрескул Алексей,

 

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

Потом еще как вариант - плокировка страницы

 

https://academy.terrasoft.ru/documents/technic-sdk/7-16/kak-polnostyu-z…

https://academy.terrasoft.ua/documents/technic-sdk/7-16/mehanizm-blokir…

 

Использую и вариант с БП и с блокировкой страницы, но если нужна более гарантирования возможность блокировки то второй вариант

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

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

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

Насколько понимаю, нет, не перетрут. Пишут:

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

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

 

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

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

Мы просто запрещаем пользователям менять права вручную. И автоматизируем распределение прав полностью. 

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

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

 

Как это можно сделать?

Нравится

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

Добрый вечер.

 

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

 

Если есть существующие записи, то их можно обновить sql-запросом.

Добрый вечер.

 

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

 

Если есть существующие записи, то их можно обновить sql-запросом.

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

Добрый день!
Подскажите как можно добавить фото Контакта и Контрагента в реестр и на страницу в мобильной версии Creatio.

Нравится

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

Так стандартно фото есть и в реестре, и в карточке:

scr_mobile_overview_main_wizard.pngscr_mobile_overview_look_inside.png

А если Вы хотите с телефона добавить фото конкретному контакту, то вроде бы стандартными средствами нельзя.

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

Доброго дня. 

Есть в системе Контрагент, и есть Контакт у этого Контрагента.

И есть ответственный, как у Контрагента, так и у Контакта.

Однако, если у Контрагентов один Ответственный - это ведущий менеджер, то у Контактов пользователь Supervisor.

Как бы привести в соответствие ответственных из Контрагента в Контакты. Не в ручную, а автоматизированно. 

 

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

Если это так, то подскажите, какая документация может помочь? 

Или если не бизнес-процессы, то что? 

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

Нравится

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

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

update c
set OwnerId = a.OwnerId
from Contact as c
join Account as a on c.AccountId = a.Id
 
либо (в зависимости от связи)
 
update c
set OwnerId = a.OwnerId
from Contact as c
join Account as a on c.Id = a.PrimaryContactId

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

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

update c
set OwnerId = a.OwnerId
from Contact as c
join Account as a on c.AccountId = a.Id
 
либо (в зависимости от связи)
 
update c
set OwnerId = a.OwnerId
from Contact as c
join Account as a on c.Id = a.PrimaryContactId

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

Сидоров Александр В.,

То есть в бизнес-процесс можно зашить этот скрипт?

Bogdan Zozulya,

Да, можно. Элемент "Задание сценарий", в нем вызов CustomQuery

Можно, но не нужно. Внутри БП для этого есть более подходящие способы: элементы чтения и изменения данных или работа в скрипте с EntitySchemaQuery.

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

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

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

Bogdan Zozulya,

С документацией по настройке бизнес-процессов можете ознакомиться по этой ссылке на Академии и более подробно по работе с данными здесь.

Алла Савельева,

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

Можно сделать два отдельных механизма: один — для разового запуска в начале, другой — постоянно готовый сработать БП на событии изменения поля «Ответственный» контрагента: получаем значение поля и элементом изменения данных меняем ответственного во всех контактах, у которых указан этот контрагент.

Bogdan Zozulya,

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

Алла Савельева,

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

Сидоров Александр В.,

А как разницу связей выявить? Куда мне посмотреть, чтобы определить какой из вариаций скрипта мне подходит?

В зависимости от того, как связаны интересующие контакты с контрагентом: по полю в контрагенте «Основной контакт» или наоборот, по полю в контакте «Контрагент».

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

Понял, внимательно изучил, второй вариант, по полю «Контрагент» в «Контакте». Выходит второй вариант скрипта. верно?  

update c
set OwnerId = a.OwnerId
from Contact as c
join Account as a on c.Id = a.PrimaryContactId

Нет.

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

Добрый день. Нужно решение такой задачи.

"Каждый ответственный видит только своих контрагентов"

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

Фильтрами + права доступа, или бизнес процессом. Поделитесь пожалуйста опытом.

Спасибо

Нравится

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

Здравствуйте, Григорий!

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

"своих контрагентов" - это тех, которых он создал? Или тех,  в которых он ответственный?

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

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

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

1) Вшить в раздел Контрагенты фильтр или группу, которую нельзя снять. Идельно - дать пользователю возможность выбирать 1 из групп, но запретить любую прочую фильтрацию, или доступ к реестру без группы.

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

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

Нравится

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

Данил. Вам стоит смотреть в сторону замещения метода initQueryFilters в разделе. Он будет фильтровать записи при загрузке раздела и физически снять его пользователи не смогут.

В лиде делать выбор не из объекта Контрагенты, а из объекта, построенного на VIEW (заодно и покажете только те поля, которые хотите показать).

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

Добрый день!

 

Есть 75 Контрагентов, который нужно сменить Ответственного. Каким образом это можно сделать?

Нравится

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

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

Добрый день. Самый оптимальный вариант - написать UpdateQuery. Вы можете задаться вопросом, почему бы не сделать это непосредственно в базе с помощью SQL скрипта? Дело в том, что данный вариант не затронет бизнес-логику приложения, как минимум - новому Ответственному не будут выданы полные права на запись, а также не будут запущены процессы, которые начинаются на изменение Ответственного. В то время как вариант с UpdateQuery идентичен изменению Ответственного в интерфейсе приложения.

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

Собственно вопрос в заголовке.
Дело в том, что в лиде это отдельные схемы контейнеров LeadAccountProfileSchema и LeadContactProfileSchema.
А мне нужно вывести список контактов выбранного контрагента.
Как организовать данный фильтр? Пробовал замещать карточку лида и в ней указывать но не работает.
Да и не понятно какие колонки они используют? Такие: Account и Contact? Или что-то другое?

Можете дать готовое решение или хотя-бы объяснить всё понятно.

Нравится

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

Добрый день, Максим!

Думаю, самый простой вариант - добавить бизнес-правило. Если у Вас 7.10 - можно через мастер, если нет - то в карточке. Поля, которые Вам нужно - QualifiedContact и QualifiedAccount, это можно подсмотреть в объекте. Просто Contact и Account - это текстовые поля, а не справочные. Насколько я понимаю, потому что в момент создания лида не всегда они известны, да и можно написать название с ошибками.

"Мотков Илья" написал:

Добрый день, Максим!

Думаю, самый простой вариант - добавить бизнес-правило. Если у Вас 7.10 - можно через мастер, если нет - то в карточке. Поля, которые Вам нужно - QualifiedContact и QualifiedAccount, это можно подсмотреть в объекте. Просто Contact и Account - это текстовые поля, а не справочные. Насколько я понимаю, потому что в момент создания лида не всегда они известны, да и можно написать название с ошибками.

Спасибо. Помогло с этими полями - QualifiedContact и QualifiedAccount!

"Сазонов Максим" написал:А мне нужно вывести список контактов выбранного контрагента.

Вывести где ?
по нажатию кнопки, по наступлению какого-то события или состояния, при открытии карточки ?
В общем и в целом ничего сложного в Вашем кейсе нет.
Необходимо задать себе несколько вопросов:
1) Как связаны целевые Контрагент и Контакты (я подразумеваю что речь идет о детали "Контакты Контрагента") ?
2) Что мне необходимо сделать концептуально, н/п "У меня есть справочное поле контакт, и мне необходимо чтобы пользователь выбрал там значение из "открывающегося окна выбора"/"из выпадающего списка"(нужное подчеркнуть), при этом доступный список контактов должен быть отфильтрован по принципу присутствия в детали "Контакты Контрагента", для контрагента который в данный момент у казан в справочном поле контрагента текущей карточки".

Ответьте мне на эти вопросы, и я помогу Вам реализовать Ваш кейс.

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