Хм, интересно, как такое осуществить?
К примеру запрос:

ВЫБРАТЬ
   Контрагенты.Ссылка
ИЗ
   Справочник.Контрагенты КАК Контрагенты
ГДЕ
   Контрагенты.ИНН ПОДОБНО &ИНН

&ИНН - это у нас список значений ... как бы такое осуществить :)

ВЫБРАТЬ
   Контрагенты.Ссылка
ИЗ
   Справочник.Контрагенты КАК Контрагенты
ГДЕ
   Контрагенты.ИНН ПОДОБНО &ИНН1
или
   Контрагенты.ИНН ПОДОБНО &ИНН2
...
или
   Контрагенты.ИНН ПОДОБНО &ИННN

(0) что-то не так
зачем подобно, если ИНН имеет фиксированную длину

ВЫБРАТЬ
   Контрагенты.Ссылка
ИЗ
   Справочник.Контрагенты КАК Контрагенты
ГДЕ
   Контрагенты.ИНН В(&ИНН)

(2) не прокатит, нужно условие ПОДОБНО

(3) приведи пример подобно для ИНН,
очень интересно

(1) можно конечно и так, но если этих условий будет N .. ой запросище страшный будет.

ВЫБРАТЬ
   Контрагенты.Ссылка
ИЗ
   Справочник.Контрагенты КАК Контрагенты
ГДЕ
   Контрагенты.ИНН ПОДОБНО "772%"

(4) если что, ИНН - это строка ;)

(5) формируй текст запроса в цикле...

(7) т.е. опять по условию ИЛИ .. других вариантов нету?

(6) Ну и... Чем (2) не устраивает при условии, что >>&ИНН - это у нас список значений

(8) используй % и *

хотя для меня поиск контрагента по ЧАСТИ ИНН тёмен

(9) банально тем, что это не работает :)

(9) а не работает потому что у меня кусочки ИНН ;) а не точные значения

(12) чем тебе (7) не нравится? ты же текст запроса не на печать выводить будешь?

в твоем нике ошибка в т.ч.
Ivanhoe

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

(12) для кусочков кроме склейки запроса и % решений нет

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

(17) вот это ни хрена себе...

Одумайтесь. Сравнение строк по шаблону - это не сравнение ссылок. Это плохое решение. Я бы даже сказал - не совсем хорошее.

(17) ошибка в постановке задачи,
возможно она(задача) имеет не неожиданные решения,
но ты о них не узнаешь,
поскольку упёрся в конкретный запрос

(19) согласен, может быть вместо справочника кусочков ИНН заполнять его по кусочкам ИНН и тогда можно использовать в(&ИНН)

(20) ктож сказал, что я уперся

(22) тогда начни от печки,
каков источник кусков ИНН

Чем вам регион не нравится? Штатно же, даже правила ограничений уже настроены.

(24) в УТ нет такой связи, регион не обязательное для заполнения поле

Можно так:

ПОДСТРОКА(ИНН,1,2) В (&СписокСтрок)

Во... придумал как осуществить:

ВЫБРАТЬ
   Контрагенты.Ссылка
ИЗ
   Справочник.ДоступныеИНН КАК ДоступныеИНН
       ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты
       ПО (Контрагенты.ИНН ПОДОБНО ДоступныеИНН.Наименование)

где наименование будет кусочек ИНН%

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

регион от ИНН отличается, если филиал в другом регионе, то ИНН у них вроде как с головным офисом общий

(28) скажем так, не удобно это использовать ;)

(30) см (26)

(26) прикольно...

(31) вон в (23) правильный вопрос задают. ты бы ответил.

(31) немного не подходит, точное количество символом мне никто не сказал, по-этому  :)

Всем спасибо, я забыл Вам написать, что кусочки ИНН - это справочник, с которым можно устроить связь, так что решение очень простое :) в (27) описал его

"кусочки ИНН - это справочник" о как

(36) угу .. с самого начала не правильно задачу поставил :(

Вопрос о совпадении инн у филиала в другом регионе очень правильный. Но еще не ясно, недостаток это или фича. Может они из-за этого потом будут еще и кпп сравнивать :)
А самое главное, этот медленный запрос будет внедряться везде, где будет происходить контроль доступа.

Собственно говоря в этом и есть задача, контроль доступа на уровне регионов ;) Но, к сожалению, регионы в базе в унынии :)

Задача ваша в том, чтобы регионы привести в порядок. Перестаньте программировать, пользуйтесь программой, которую вы программируете, и будет вам счастье.

Регионы, к стати, можно загрузить с ИТС. У них коды, даже, имеют связь с инн, если память мне не изменяет.

(40) эх, я только посоветовать могу, а захотят они или нет - уже другой вопрос.

решение в (27) пратформо-зависимое
(читайте доки по like)

предлагаю заменить его на
такое: в таблицу(справочник ) "ДоступныеИНН" добавить еще одно  поле
(допустим "Наименование_MAX")

в нем будет содеожаться копия поля "Наименование" + символс максимальным кодом
(1с8 юникодовая);

потом отбор строить соединением с этой таблицей
по условию

(Справочник.Контрагенты.ИНН >=   ДоступныеИНН.Наименование)
AND
(Справочник.Контрагенты.ИНН <    ДоступныеИНН.Наименование_MAX)

именно так и сделает MS SQL в случае если    Контрагенты.ИНН - индексированно.

поэтому предлагаю ему помочь :).

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

сответственно получим плаатформо-независимое решение -
универсальность штука дорогая

--------------

к томуже замечу, что 1с8 конструкцию "В"
В НЕКОТОРЫХ случаях реализует через EXIST для MS SQL serv
что весма не производительно.

(43) только надо еще в число преобразовать :) Тогда будет работать, а так там строка и вести себя она будет не как число :)

(44)
ерунда полная.
1c8 прекрасно сравнивает строки.

строка и не должна вести себя как число.
читайте что такое colation

(45) ерунда когда клиент укажет минимальное значение 1, максимальное значение 2 .. в итоге попадут ИНН начинающиеся на 10 ... это к примеру о сравнении строк .

Все не читал. Но 0 можно сделать - преобразовать список значений в строку с разделителями. Тогда подобно будет работать.

можно список во временную таблицу и связка <по ... подобно ...>, ИМХО

(45) в общем МихаилМ Вы правы только в том случае, если указывать ИНН полностью все 12 знаков, хотя .. почему-то кажется, что все-равно проверять надо ... не верю я в это сравнение строк ...

то (49)
как проверяли ?

неужели строка "223" < "2223"

см (48)
пример:

select t1.f1, t2.f2 from
(select 'as' as f1
union all
select 'ds') t1
inner join
(select 'asff' f2
union all
select 'sdff'
union all
select 'ffds') t2
on t2.f2 like '%' + t1.f1 + '%'

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

(50) проверял на банальном варианте сравнения 10 с 1 и 2 .. 10 >= 1 и 10 < 2 результат = Истина.

(52)
так что непонятно ?
так и должно быть.

(54) проснулся я , в общем :D А-то начинается на 1 и начинается на 10 для меня разное было :D