Есть 2 внешние обработки с наименованиями
1) "Расчет базы распределения косвенных расходов"
и
2) "Расчет базы распределения косвенных расходов + НДС ставка 0"
Есть поиск
ВнешниеОбработки.НайтиПоНаименованию("Расчет базы распределения косвенных расходов")
Без точного поиска, то есть второй параметр "Ложь"
У всех пользователей находит №1, у одного №2, ставлю второй параметр "Истина", находит №1

Судя по кодуСправочника №2 введен раньше №1

Платформа 20-я, ОФ, почему так?

кеш пользователя прибивал и
проверял со своего компа с загрузкой со своего конфигуратора, путем подмены пользователя в параметрах, то есть кеш отметается(вроде бы как, ИМХО)
ПыСы холивар разводить, что ПоискПоНаименованию() - дичь, не стоит, я знаю, имею что дали

Просто ПоискПоНаименованию() - дичь, не стоит. Переделай, быстрее будет, чем на форуме глупости обсуждать, дел то на 2 минуты.

(0) Ответ на этот вопрос никакого практического смысла не имеет.
1С всегда и везде писала, что результат поиска по наименованию предсказать точно невозможно.
Даже если кто-то тебе сейчас выдаст какое-то обоснованное объяснение, ты не сможешь никак применить его на практике.
Бессмысленная трата времени.

Единственное что ты можешь - сделать по-человечески. А уж тут вариантов масса. Начиная с того, чтобы объединить обработки в одну, работающую в двух режимах (для основной ставки НДС и ставки 0%). И заканчивая переносом обработок в расширение и использование вместо поиска по наименованию обращение по именам.

Ставь всегда истину. И задавай точное наименование

(0) Скорее всего, файловый режим?

>> У всех пользователей находит №1, у одного №2.

Придётся теперь этого пользователя увольнять. 1С не для него.

(1) (2) (3) Это понятно, в данной ситуации, быстро решить эту проблему - это переименовать №2, это я знаю
как в принципе все что удалось накопать с просторов , что поиск по наименованию зависит от температуры теплого океана и фазы луны
(4)К-С, МС Скуль

Еще промелькнуло мнение, что МенеджерСправочников зафиксировало "частое" обращение этого пользователя с поиском по наименованию этой обработки и закешировало себе, и после обращения НайтиПоНаименованию, не лезет в БД, а выдает сразу кешированный результат (ну так на детском языке если)

(7) Как-то сомнительно. При таком варианте менеджеру справочника пришлось бы отслеживать изменение состава элементов (добавление/удаление) и их наименований. Чтобы актуализировать этот кэш. Да ещё и в разрезе каждого пользователя. Не слишком ли сложно.

(6) Сортировка по какому реквизиту?

(9) какая сортировка, я где то про сортировку что то говорил?

Гуру подтянулись. :-)

Может там вообще у пользователя какие-то особенные права. И в текст непосредственного запроса к БД добавляются RLS. Потому и результат запроса отличается.

все же работает правильно, согласно описанию. Находит? Находит.

(12) Ник4аких особенных, рядом такой же бух сидит с полностью идентичными правами, находит №1, ц второго 2, но у кого находит не правильно - работала до этого с обработкой №2, потом ее, №2 переделали и залили как новую, но находит старую, при переименовании старой, или при параметре Истина, то находит и использует новую без проблем, отсюда и появилась версия из (7)

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

(15) Если и есть индексированная таблица(а она есть), да даже кластерная индексация, то она как бы должна для всех выполнятся одинаково и от сортировок пользователя это уж никак не зависит

если сортировка не указана (а она не указана), то найтись может любой.
Приучайся делать запросами

(17) Быть тебе главой Почты России! 😀😀😀
А если не запросами, то указывай сортировку.

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

(18) без запроса нельзя сортировку указать

(19) это тебе нужно понимать внутреннее устройство файлового движка

ищи по коду, делов то)

(16) >> должна для всех выполнятся одинаково и от сортировок пользователя это уж никак не зависит.

Чистой воды домыслы и попытка выдать желаемое за какое-то правило.
Причем в условиях, когда вендор явно указывает, что никаких правил нет, и никому 1С в этом вопросе ничего не должна. А у тебя "должна" и всё тут.

(23) У вас тоже чистой воды домыслы исходя из- "и никому 1С в этом вопросе ничего не должна"

(24) + Из за таких же суждений, завтра 1С при одинаковых входных параметрах будет выдавать разный результат расчетов из регистров, к примеру, то тоже "и никому 1С в этом вопросе ничего не должна", а что удобненько так то...

(25) поэтому см (17)

(0) Ты на других языках программировал? Знаешь, что такое undefined behaviour? Вот это оно. Попытки выяснить причину смысла не имеют. Причина разумеется есть, посмотрев исходники платформы, можно ее найти, а толку? Косяк данного решения НайтиПоНаименованию на 1С не спишешь, как ни крути.

Это примерно как знакомая продавщица в магазине все время давала в долг, а сегодня бац — за прилавком другая и посылает нах. А ты, весь такой в праведном гневе, идешь жаловаться директору.

(27) (28) Какие то нелепые примеры и оправдания, извини не впечатлило...
и что то мне думается на других языках за подобное разрабов бы по голове не погладили бы, особенно в более серьезных системах...

(29) "разрабов бы по голове не погладили бы" это вы про коллег, которые код (0) написали? :-)

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

(31) ЗаиЙсаль, НайтиПоНаименованию - не документированная функция, ок, ветку можно закрывать...

(25) >> Из за таких же суждений.

Каких суждений? Ты бредишь? В документации явно прописана особенность работы метода НайтиПоНаименованию(). Ты же пытаешься всех убедить, что такой особенности быть не должно. Если бы её не должно было быть, то её и не было бы. Но она есть. Нравится тебе или нет. Просто прими это как данность.

>> завтра 1С при одинаковых входных параметрах будет выдавать разный результат расчетов из регистров.

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

Претензии имело бы смысл предъявлять, если бы 1С никого не предупредило бы или вообще гарантировало бы, что будет один результат, а выдавался бы другой.

Я в типовой ЕРП 2.5. находил более ста вхождений "НайтиПоНаименованию"...

ЗЫ
Расстрелять!

Представим, что в справочнике 1000 элементов с абсолютно одинаковыми наименованиями и кодом. То есть не как в (0), где наименования всё таки различаются, а именно одинаковые.
Какой именно элемент должен вернуть результат поиска по наименованию?
Что, по-твоему, должна указать 1С в документации к этому методу, если наблюдает различные результаты на различных СУДБ и даже на различных версиях одной и той же СУБД?

(35) Который первый в списке! :))

p.s. А если после ТИИ будет другой, это предательство!

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

(34) Тсссыыыы, это недокументированная функция, только для служебного пользования с неизвестным результатом, гыыы
(33) Хватит натягивать сову на глобус
(35) Должен быть один результат, по какому признаку пусть, как ты говоришь - вендор сам выберет и им пользуется, дата создания, гуид, код, индекс и хер пойми чего, но один и тот же, или выдавать сз со списком найденных результатов, ту уж пусть сами выбирает какой прогеру более подходит(это же касалось бы по коду, по реквизиту и т.д.)

(38) >> Хватит натягивать сову на глобус.

+100500. Именно этим ты сейчас и занимаешься. Сам себе что-то придумал и теперь пытаешься всех окружающих убедить в незыблемости своей "правоты".

(37) "один и тот же элемент для разных случаев - это уже сугубо ваши проблемы." Читать умеешь, нет так перечитай(0)?
Какие нахер разные случаи и параметры, из разных параметров - другой пользователь и все, даже параметры запуска одни и те же из конфигуратора

(38) Вот вендор и выбрал признак "хер пойми чего" с правом его менять по своему усмотрению.
Иначе было бы невозможно развивать платформу.

(39) еще раз, я себе ничего не придумал, а попытался понять и вас спросит от чего зависит, но в (6) уже сделал выводы "что поиск по наименованию зависит от температуры теплого океана и фазы луны", дальше этого мы не сдвинулись ни на микрон

Так это скуль? Тогда пишите в спортлото (зачеркнуто) Микрософт

- Ты суслика видишь?
- Нет.
- А он есть.
(С)
Описание ветки в трех строчках.

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

(0) вот так ищет БСП, применяй

Функция КонфликтующиеДополнительныеОтчетыИОбработки(Объект, ЭтоОтчет, ИмяОбъекта)
    УстановитьПривилегированныйРежим(Истина);
    
    ТекстЗапроса =
    "ВЫБРАТЬ
    |    ТаблицаСправочника.Ссылка КАК Ссылка,
    |    ТаблицаСправочника.Представление КАК Представление
    |ИЗ
    |    Справочник.ДополнительныеОтчетыИОбработки КАК ТаблицаСправочника
    |ГДЕ
    |    ТаблицаСправочника.ИмяОбъекта = &ИмяОбъекта
    |    И ТаблицаСправочника.Вид В(&ВидыДополнительныхОтчетовИОбработок)
    |    И ТаблицаСправочника.Публикация = ЗНАЧЕНИЕ(Перечисление.ВариантыПубликацииДополнительныхОтчетовИОбработок.Используется)
    |    И ТаблицаСправочника.ПометкаУдаления = ЛОЖЬ
    |    И ТаблицаСправочника.Ссылка <> &Ссылка";
    
    ВидыДополнительныхОтчетовИОбработок = Новый Массив;
    ВидыДополнительныхОтчетовИОбработок.Добавить(Перечисления.ВидыДополнительныхОтчетовИОбработок.ДополнительныйОтчет);
    ВидыДополнительныхОтчетовИОбработок.Добавить(Перечисления.ВидыДополнительныхОтчетовИОбработок.Отчет);
    
    Запрос = Новый Запрос;
    Запрос.УстановитьПараметр("ИмяОбъекта",     ИмяОбъекта);
    Запрос.УстановитьПараметр("ВидыДополнительныхОтчетовИОбработок", ВидыДополнительныхОтчетовИОбработок);
    Запрос.УстановитьПараметр("Ссылка", Объект.Ссылка);
    
    Если Не ЭтоОтчет Тогда
        ТекстЗапроса = СтрЗаменить(ТекстЗапроса, "ТаблицаСправочника.Вид", "НЕ ТаблицаСправочника.Вид"); // не локализуется
    КонецЕсли;
    
    Запрос.Текст = ТекстЗапроса;
    
    Конфликтующие = Запрос.Выполнить().Выгрузить();
    Возврат Конфликтующие;
КонецФункции

Хм... Любопытная фигня. Действительно интересно, чем конкретно обусловлена разная выдача для разных пользователей (в плане лучшего понимания внутренней механики).
И да - действительно было бы лучше, если бы при поиске при наименованию платформа стабилизировала бы выдачу явной сортировкой.
ЗЫ. Что не отменяет того факта, что использовать неточный поиск - это быть ССЗБ.

А что значит НайтиПоНаименование("ЧтоТо",Ложь)..?
найдет первую любую какую-то значение которое Начинается с "ЧтоТо"..?
то есть в ответ можно получить и
"ЧтоТо"
или
"ЧтоТоКомуТо"
.
иликак ?

(48)Именно так, Читай (0), там все написано, почти всем выдает ЧтоТо, а не понятно почему, кому то "ЧтоТоКомуТо"