Добрый день!

Да. Оба пункта действительны. При изменении Last name или Middle name или First name, изменяется поле Full name и наоборот. 

Логика разделения ФИО контакта на Surname GivenName MiddleName настривается системной настройкой ContactFieldConverter, выбором необходимого с# конвертера, которые находятся в таблице ShowNamesBy.

В базовой функциональности существуют два конвертера First name [Middle name] Last name и Last name, First name [Middle name]. 

Оба шаблона включают Middle Name.

Указанные поля заполняются автоматически на основании данных, которые внесены в поле ФИО, с учетом разделителей. В качестве разделителя система распознает пробел и . , ;

Для заполнения по умолчанию используется конструкция "Фамилия, Имя и Отчество" и разделяется на "Имя" и "Фамилия" согласно формата ФИО (Фамилия Имя Отчество).

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

Владимир,

Вы можете воспользоваться кнопкой "Квалифицировать" (скриншот) для автоматической генерации Контакта и Контрагента на основе регистрационных данных (скриншот). Эта кнопка также доступна из реестра записей раздела (скриншот).

Более подробная информация о квалификации лида находится на сайте академии в статье Квалификация лида.

"(очень справедливое)" - справедливости в этом мире нет. Поэтому придётся ручками на странице лида подписываться вот на это сообщениеНу и возвращать список дефолтных значений.



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

Соротюк Татьяна пишет:

Вы можете воспользоваться кнопкой "Квалифицировать" (скриншот) для автоматической генерации Контакта и Контрагента на основе регистрационных данных (скриншот). Эта кнопка также доступна из реестра записей раздела (скриншот).

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



Будем пробовать предложенный вариант. Спасибо!

Здравствуйте,
Дело в том, что деталь, это отдельный объект в системе. В вашем случае объект детали "средства связи контакта": «ContactCommunication». А сама карточка контакта, другой объект (таблица в бд): "Contact", в которой самые основные средства связи продублированы, к примеру, как вы продублировали, создав поле "Доп. email". Но что бы оно заполнялось, необходимо написать соответствующую логику. К примеру, вы можете создать бизнес-процесс для этой цели, по событию создания экземпляра ContactCommunication, и в связанный контакт при этом, элементом «изменение данных», записывать сохраняемый дополнительный E-mail из детали в контакт. Подробнее про БП читайте в цикле статей на академии:
https://academy.terrasoft.ua/documents/technic-bpms/7-8/obzor-vozmozhno…

Максим Шевченко пишет:

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

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

Как расширить базовую логику, чтобы синхронизировались доп. поля? 

"Гольфельд Елена Андреевна" написал:В карточке контрагента есть поле "Домен e-mail"

поле "Домен email" это постоянное поле? или данное поле создано в средствах связи контрагента. поясните данный момент.

"Гольфельд Елена Андреевна" написал:Как это реализовать? Ведь я от контакта получаю почту "123@gmail.com", а в домене контрагента указан gmail.com

а в этом вам поможет следующая документация с сайта Майкрасофт. String.Split

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

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

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

В системе такая логика реализована при загрузке писем в систему - на деталь "Участники активности" добавляются контакты, у которых на детали средство связи есть записи, которые совпадают со значениями в поле "От кого", "Кому", "Копия". Поскольку в email приходят значения вида test@test.test<'Test email user'>, то данное выражение по регулярному выражению преобразовывается в email вида test@test.test. И уже после преобразования значения сравниваются.

Здравствуйте, Эмин!
Это типичная задача. следующим кодом в замещающем клиентском модуле:

structure.userCode = function() {
...
	this.actions.push({
		caption: resources.localizableStrings.ActionCaption,
		methodName: 'actionMethod'
	});
	this.methods.actionMethod = function() {
		alert('test');
	};
...
};

"Андрей Каспаревич" написал:

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

Это типичная задача. следующим кодом в замещающем клиентском модуле:

structure.userCode = function() {

...

        this.actions.push({

                caption: resources.localizableStrings.ActionCaption,

                methodName: 'actionMethod'

        });

        this.methods.actionMethod = function() {

                alert('test');

        };

...

};

С уважением,

Каспаревич Андрей

Эксперт 3-й линии поддержки

Uncaught TypeError: Cannot read property 'push' of undefined 

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

var myActions = [];
myActions.push({
 caption: resources.localizableStrings.Name,
 methodName: 'Method'
});
this.actions = myActions;

Еще раз спасибо за помощь!

Эмин, рад, что Вы разобрались! Я как раз забыл это упомянуть.