Есть задачка при создании документов проверять а нет ли уже ранее загруженных (похожих) в базе.
Никакого уникального индекса/кода к сожалению нет.

Допусти ищем по реквизитам шапки:
Организация, Партнер, ДатаВходящегоДокумента, НомерВходящегоДокумента

Так же надо учитывать в ТЧ Расходы совпадение по строкам для реквизитов Содержание и Сумма

Каким образом лучше то сделать?

(0) оптимально - индекс сформировать. остальное будет криво и медленно

(1) Не хотелось бы

(1) причем, индекс можно формировать отдельно от документа, например, выделив под него рс

(3) в расширении..

(2) почему не хотелось бы?

(3) Хорошо как сформировать этот индекс-хеш?

(0) выбрать по реквизитам шапки и свернуть где количество больше 1. Потом сравнить в цикле либо запросом

(7) а, хотя не, тебе же надо при создании это делать, а не разово

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

(7) ТЧ надо учитывать

Голосую за контроль уникальности по доп реквизиту

(9) или по уиду

(12) т.к. наименования могут и поменять

(6) Рядом же тема была про ТЧ справочника/документа)

я просто это в клюшках решал на массе, других нормальных вариантов нет

(0) Определите для вас ключевые поля, по которым вы определяете "схожесть", пол дела уже сделаете)

(6) (10) какой-нибудь MD5 для строки "Организация+ Партнер +ДатаВходящегоДокумента +НомерВходящегоДокумента + ТЧ расходы

сцылочные типы по GUID, содержание и сумму из ТЧ выгрузить в массивы с сортировкой и тоже в строку

щас выяснится что содержание в произвольном виде и нужно вхожения искать :)

(16) Это уже сделано
Загвоздка отбора похожих с учетом что не только реквизиты шапки но и ТЧ

(14) Вот эта тема сравнение ТЧ

(17) >>щас выяснится что содержание в произвольном виде и нужно вхожения искать :)
ну вот это как раз совсем не сложно, упорядочиваешь те же GUID
Но я против что бы каждый раз всё это на лету считать. При создании у новых записываешь это всё допреквизитом (или реквизитом), а при проверке нового - тебе надо вычислить этот хэш всего лишь 1 раз

(18) Значит не сделано, раз вы не решили, что для вас значит со схожими ТЧ)

(18) Почитайте (19) там в конце есть варианты реализации

(20) содержание баба маня может ручками с ашипками написать. но даже ежу понятно, что это одно и тоже

"гусь лапчатый" и "лапчатый гусъ"

(23) А это уже совсем другая задача и куда сложнее)

(21) >со схожими ТЧ
1. Количество строк совпадает
2. Порядок строк не имеет значения
3. Колонки Содержание (строка) и Сумма (число) совпадают

(23) у него содержание ТЧ - ссылки и числа, насколько я понял.
Если когда он пишет про "похожий" - это текст, то сюда только нейросеть прикручивать разве что :-D

(25) Берете и создаете строку, которая включает в себя все 3 пункта и хешируете. А дальше уже по этому хешу и сравниваете

(26) строка и число

для строк нечеткого поиска не надо

(27) В запросе как?

(25) ну тады прокатит такая магия для >Колонки Содержание (строка) и Сумма (число) совпадают

содержание и сумму из ТЧ выгрузить в массивы с сортировкой и тоже в строку и вычислить хэш

(29)+ без предварительной функции хеширования кодом

(29) Легко!
Выбрать МойРС.Док Из РегистрыСведений.МойРС ГДЕ МойРС.ХешСумма=&ХешСумма =)

(31) микросервис на GO!

(31) С этим то в чём проблема?...

(0) учитывая, что параметры поиска строковые и числовые - в индекс не попадешь.

у меня давно работает система группировки аналитик

1. делаем справочник "аналитика", у него ТЧ с ПВХ тех характеристик которые надо искать
2. добавляем реквизит в объекты поиска (в твоем случае в строки ТЧ документа), или можно сделать РС
3. при необходимости проверки берем из документа набор характеристик и ищем по ним элементы справочника "аналитика", при необходимости - создаем.
4. далее простой запрос....

(29) Если вам разово надо, то проще в цикле обойти

Если лень РС создавать, то можно типовой использовать, например ДополнительныеСведения.

(35) в ERP у тебя идею с3.14тырили:)

(36) угу
запросом отбираю документы по реквизитам шапки
далее цикл по отобранным документам для сравнения ТЧ

(38) я пользуюсь уже 7 лет :)

(39)+ но хотел все одним запросом провернуть, не получается

(39) Можете еще по количеству строк и Сумме отобрать. Гораздо меньше придется обходить в цикле

(41) почитай про "критерии отбора" может он подойдет

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

(42) Можно, но не обязательно дата и номер дают хорошее ограничение

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

(45) Как вариант - создать временную таблицу с ключевыми полями для поиска в ТЧ. И уже с ней соединять таблицу строк документа с отбором по реквизитам шапки.

(46) Не совсем.
Классическая ситуация когда по просьбе клиента вручную в 1С создают приход услуг чтобы создать заявку на оплату и побыстрей оплатить.
А массовая загрузка документов прихода услуг из другой системы будет позже.
И будет включать и созданный вручную

(48) *по просьбе поставщика

(49) Есть номер входящего документа и дата входящего документа. По ним и синхронизируйте. То что введено вручную, должно иметь эту связку

(50) Недостаточно
По одному поставщику в один день может быть несколько документов с разными содержимым в ТЧ

(51)+ и оба "Б\Н"

(51) А как вы банк сводите?) Если несколько документов за один день, то у каждого будет свой уникальный номер поставщика.

Отбор будет по поставщику,дате,номеру

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

интересно https://infostart.ru/public/326983/

(53) Это не банк, а документы от поставщиков услуг

(55) Если такая ситуация выявится то критерии поиска будут исправлены

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

(59) Он не фейковый а вручную созданный вместо загрузки
Еще могут быть сбои при загрузке, например дважды тоже самое или произошел вылет при загрузке и недогрузилось
Повторно запускают надо чтобы нашел что уже создано и не делал дубли

(60) а зачем вручную создавать? для резервов товаров штоле? виртуальный приход?

(60) Как все запущено.

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

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

(63) может
но это уже другая задачка

(62) до этого этапа еще не дошли
даже поиск дублей мое предложение, в ТЗ нет

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

(65) > до этого этапа еще не дошли

- жена! неси тазик...

- концепция поменялась, я обо.срался

(67) это будни нового внедрения и работы на проектах

В данном конкретном случае интересовало как только одним запросом найти "похожие" с учетом ТЧ документы

Ну там отобрать доки по шапке и соединить каким то местом с отобранными строками ТЧ

(60) а количество документов какое при загрузке?

в таком случае нужно через промежуточную форму грузить - оператор глазками смотрит расхождения/коллизии и ручками подбирает нужный вручной документ в случае непонятной ситуёвины

ну т.е. для 100 документов при загрузке 10 сопоставилось, с остальными что делать? считать, что новые от поставщика? ну и сбоку список вручных документов несопоставленных должен болтаться, чтобы оператор баба Шура призадумалась и постаралась сопоставить

существо разумное должно быть разумнее автоматической загрузки

(70) нафик-нафик сопоставление при загрузке еще делать
достаточно вывода в отчет/лог и отмены загрузки полностью