Здравствуёте!
Реализовать поиск дублей при сохранении достаточно не просто. Но если вкратце:
1. Заместить метод getDataForFindDuplicatesService в DuplicatesSearchUtilitiesV2
2. Унаследоваться от класса SingleRequest из SearchDuplicatesService и добавить своё свойство.
3. Создать свой SingleRequesListener чтобы заменить вызов SingleRequest на свой класс
4. Унаследоваться от DeduplicationProcessing и изменить методы AddElementsToRow и GetPreparedXml из SearchDuplicatesService
5. В хранимкке tsp_FindDuplicate нужно изменить под себя CreatingObjectInfo

На счёт "произвольного вызова" - можно, просто надо вызывать тот же метод, что и при сохранении вызывает поиск дублей.

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

Дело в том что вызывается метод this.findOnSave(callback, scope) со своим скоупом и колбэком, а откуда они берутся не понятно, потому что гуляя так по колбэку внутрь приходишь к all-combined.js и всё, конец..

"Zaitova Liubov" написал:и вроде как условия по наличию/отсутствию кавычек и равенстве прописных и строчных букв там в условии не задать

Сохраняйте для всех контрагентов в скрытом поле имя, по которому искать, убирая кавычки, приводя к UPPER, убирая всякие возможные части текста типа А/O, OOO и другие.

Любовь, добрый день.

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

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

Любовь, добрый день.

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

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

"Zaitova Liubov" написал:Вы хотите реализовать - это LIKE запрос по текстовому полю в таблице, в которой теоретически может быть и сто тысяч записей, и миллион.

а если делать как советовал Владимир Соколов:" Сохраняйте для всех контрагентов в скрытом поле имя, по которому искать, убирая кавычки, приводя к UPPER, убирая всякие возможные части текста типа А/O, OOO и другие.". то это уже будет equal, а не like и должно быть быстрее. все равно getEntityCollection не справится достаточно быстро? и еще вопрос - это вообще реализуемо, что можно дождаться его ответа и по результату дать/не дать сохранить?

Теоретически можно сделать что-угодно.)

Как заместить логику сохранения обсуждали буквально недавно: http://www.community.terrasoft.ru/forum/topic/25618
Можете аналогично переопределить метод save, и, допустим, строить запрос вида:
SELECT COUNT(*) FROM Account WHERE NAME = 'MyName', и если COUNT = 0 - сохранять запись, вызывая callParent. Однако, в таком случае Name в Контрагенте должен быть также без ООО, кавычек и прочего.

"Zaitova Liubov" написал:то это уже будет equal, а не like и должно быть быстрее

Боюсь, что для такой задачи даже Like недостаточно, нужно учиться у Google распознавать схожие записи, например "Аксиома" и "Аксиомаа"

"Мотков Илья" написал:Можете аналогично переопределить метод save

А может, лучше на Validation повесить?

"Владимир Соколов" написал:А может, лучше на Validation повесить?

Если можно логику выполнить синхронно то да, иначе:
http://www.community.terrasoft.ua/forum/topic/25618#comment-69035

Здравствуйте, Светлана!

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

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

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

Здравствуйте, Светлана!

Для того, чтобы установить причину, проверьте следующее:

1) подключили ли Вы свою хранимую процедуру (проверить можно в окне настройки правил поиска дублей), так как если Вы внесли изменения в базовую процедуру поиска дублей, то они могли перезаписаться назад, например, при пересохранениии таблицы.
2) запустите SQL Profiler и посмотрите, какая хранимая процедура отрабатывает и какой у неё текст.

Спасибо! Эту часть уже сделала, нужно было изменить фильтры для связи. Незнаю как здесь удалить опубликованные(( Тормознулась на подсчете количества, Вы мне ответили в другом топике http://www.community.terrasoft.ru/forum/topic/24760.

Здравствуйте, Светлана!

Относительно Вашего вопроса, попробуйте установить точку останова в функции PrepareSearchResults() скрипта wnd_ViewSearchResultScript и выполнить пошаговую отладку именно этой функции.

Добрый день!

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

С уважением, Анна

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

Права на поиск и объединение дублей ограничены системной операцией "Поиск дублей"
Для решения:
1) Перейдите в "Дизайнер системы"
2) Перейдите в "Права доступа на операции"
3) Найдите операцию "Поиск дублей"
4) Выдайте права нужным пользователям.

Добрый день!
Дубли в системе обрабатываются после проведения глобального поиска дублей. Найденные дубли группируются по похожести, для удобства обработки. Подробно о запуске глобального поиска и обработке его результатов рассказано в Академии.

Ксения, все верно.
После глобального поиска таких дублей обнаруживается столько, сколько я написал.
Меня интересует, есть ли способ обработки уже найденных дублей, чтобы не совершать 390 кликов "Select All" и 390 кликов "Merge". Так как не все дубли схлопнутся автоматически, возможны еще вариации из различных сотен кликов.
Потом настанет черед контактов, а их уже 1500.

Здравствуйте! Можно поинтересоваться как решили данную задачу?

Добрый день, Светлана!

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

Спасибо!

Ошибка рассматривается здесь: http://www.community.terrasoft.ua/forum/topic/10276#comment-46507

Здравствуйте, Николай.

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

"Maxim Gritsenko" написал:

Здравствуйте, Николай.

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

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

Большое спасибо за ответ!

Добрый день, Антон!

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

Спасибо

Антон, пожалуйста, предоставьте скриншот фильтр-билдера.

Выкладываю скрин:

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

Вот решали эту проблему здесь

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

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

Хорошо, спасибо, буду ждать

Антон, Вам необходимо в скрипте своего раздела в нужном месте подставить функцию очистки пользовательских фильтров, как описано здесь

Мне вот интересно, я 25 декабря писала эту ссылку, как сказано:

"Каневский Антон Владимирович" написал:Решение проблемы специфическое, относится к определенному скрипту в Проектах.

Но все-таки это оно и есть?

Пробую, как Вы сказали... Сопоставить раздел Проекты и применить это в своем, не получается. Можно, в общих чертах, описать, что нужно сделать с моими select'ами в коде?

Такое поведение компонента FiltersBuilder связано с логикой построения запросов. В компонент последовательно выводятся фильтра из SelectQuery dataset’а. Т.к. в запросе есть Union, согласно ядровой логики, пользовательские запросы добавляются для каждого select’а, т.е. 1 – union = 2 раза, 2 – union’а = 3 раза и т.д. Проблема решается конфигурационно, путём очистки пользовательских фильтров. Указанное решение рекомендуем применить, например, на BeforeOpen dataset’а грида.

спасибо. Но мне не нужно очищать пользовательские фильтры, ведь в разделе они могут быть сохранены и нужны.. А так они затираются в select'ах...

Антон, добрый день.

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

Конечно, было бы замечательно, если бы в дальнейших сборках учли эту особенность фильтров.
Кстати, версия TS XRM 3.4.0.130.
Задачу решил так: вытянул в sq sql text column, в которую вытягиваю необходимые данные (в моем случае это данные с детали моего раздела) , по которым хочу фильтровать. В датасет запроса добавляю поле с соответствующим типом. Для меня вопрос закрыт, всем спасибо

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

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