Добрый день, 

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

 

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

 

Добрый день!

 

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

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

 

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

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

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

 

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

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

 

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

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

 

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

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

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

Александр Тыра пишет:

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

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

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

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

 

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

Александр Тыра пишет:

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

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

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

 

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

 

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

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

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

Добрый день!

Ответственный у контрагентов и контактов - это тот, кто создал контрагент и контакт.

Привести в соответствие по вашему описанию можно скриптом в базе, например:

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

Нет.

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

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

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



Первый вариант решается, как описал Андрей.

Второй вариант решается бизнес-процессом

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

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

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

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

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

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

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

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

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

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

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

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

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