Подскажите, если кто-то уже разбирал этот код... Я правильно понял, что если Контрагент найден и у него имеется хотя бы один договор подходящего вида (например, для поступления на р/с - "С покупателем"), то какой-то элемент будет обязательно выбран?
Т.е. в этом случае не может быть ситуации "Договор не найден", вне зависимости от содержания реквизит "Назначении платежа".

я даже более скажу. Если небудет договора он новый создасть

(1) Создавать/не создавать - есть такая настройка, это не тот случай. Несколько другая ситуация. Ты код смотрел?

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

(3)Если искать сначала по номеру договора, а если не нашли по номеру счета и брать договор оттуда - в 99% случаях работать будет

(4) А где номер договора взять? Единственное место в банковской выписке это неформализированная строка назначения платежа. Про номер счета - не понял.
В 99% это работать точно не будет.

(4) где-нибудь уже внедрял такое?

(5) Да, именно в назначении платежа.

(3) А ты сам когда-нибудь видел результаты загрузки выписки?
В большинстве случаев, если договор имеется, то он распознаётся правильно даже наличии нескольких именно по содержанию назначения платежа.
А вот если его (договора) с нужным номером нет, то всё равно какой-то подставится.

(8) *наличии = при наличии

(4) Вопрос в том, как ищет типовой код. Я попытался разобраться, с ходу не вышло, там несколько схем поиска для различных объектов, расчёт приоритета с разными весами для разных схем...

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

(11) Дописывал. Тут: http://catalog.mista.ru/public/180797/

(11) я тоже делал подстановку счета по полю назначение платежа. Естественно клиенты пишут по разному "по счету", "по сч.", "по счету №", это всё анализировал и также если задано несколько счетов через запятую.

(13) как раз счёт более-менее системно обрабатывается, по крайней мере как один из критериев - вхождение номера назначение платежа.
(12) я правильно понял,что использовать доп. правила типа
"1. если номер договора входит в назначение платежа, и это справедливо ровно для одного договора - выбери его"
"2. если ни для одного из договоров номер не входит в назначение платежа - запиши с пустым договором, пусть пользователь сам выберет нужный"

(14) *использовать = можно использовать

(15) я своим клиентам правда на УТ 10.3 сам пилил, как раз по буковкам разбираешь назначение платежа, из банка оно приходит однотипное, таланта для этого много не надо, на основании разодранного на запчасти чешешь репу и говорит что делать тому или иному "фанту" Вид Платежа потом 1. Назначение, 2. ДДС, 3. В какое место тебе вставить проценты(плошмя или по вдоль) )), 4. Затраты(статья затрат), 5. если есть счет/заявка то исчи его там указан договор, от туда берешь, ну и далее полет извращенной фантазии

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

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

(18) Лучше написать программную обработку, т.к. простых правил заполнения придётся сделать столько, сколько договоров. И добавить ещё одно правило - если контрагент такой-то, очищаем договор. Получится на одну строку банковской выписки будет применено от одного до двух правил - очистка договора и установка в нужный если нашли соответствие.