Всем доброго дня.
Имеется элементарный запрос по документам:

Сч60 = СчетПоКоду("60.01");

Спр = СоздатьОбъект("Справочник.НазначениеТМЦ");
Спр.НайтиПоКоду(1);
ТекНазначение = Спр.ТекущийЭлемент();
    
Запрос       = СоздатьОбъект("Запрос");
ТекстЗапроса = "
|Период с ДатаНачала по ДатаКонца;
|ОбрабатыватьДокументы Проведенные;
|Поставщик  = Документ.ПоступлениеТМЦ.Поставщик;
|Договор    = Документ.ПоступлениеТМЦ.Договор;
|СчетДок    = Документ.ПоступлениеТМЦ.СчетКредит;
|Валюта     = Документ.ПоступлениеТМЦ.Валюта;
|Назначение = Документ.ПоступлениеТМЦ.Назначение;
|ТМЦ        = Документ.ПоступлениеТМЦ.Материалы;
|Кол        = Документ.ПоступлениеТМЦ.Количество;
|ЕдИзм      = Документ.ПоступлениеТМЦ.ЕдИзмерения;
|Цена       = Документ.ПоступлениеТМЦ.Цена;
|СумБезНДС  = Документ.ПоступлениеТМЦ.Сумма;
|СумСНДС    = Документ.ПоступлениеТМЦ.СуммаСНДС;
|Функция Количество = Сумма(Кол);
|Функция СуммаБезНДС = Сумма(СумБезНДС);
|Функция СуммаСНДС = Сумма(СумСНДС);
|Группировка Поставщик без Групп;
|Группировка Договор;
|Группировка Месяц;
|Группировка ТМЦ;
|Условие (Валюта = Константа.ОсновнаяВалюта);
|Условие (Назначение = ТекНазначение);
|Условие (СчетДок = Сч60);

Беда в чём:
всё отлично работает, кроме условия |Условие (СчетДок = Сч60);
как только добавляешь это условие, выборка тут же становится пустой;
если изменить условие на |Условие (СчетДок <> Сч60), то в запрос попадают вообще все счета (и равные 60.01, и не равные).

СчетДок - реквизит шапки документа "ПоступлениеТМЦ", имеет тип "Счет", переменная Сч60 естественно того же типа.
Аналогично "Валюта" и "Назначение" - тоже реквизиты шапки, но с их отбором никаких проблем нет.

Пробовал также такой вариант:
Сч60 = "60.01";
|СчетДок = Документ.ПоступлениеТМЦ.СчетКредит.Код;
|Условие (СчетДок = Сч60);
результат тот же, выборка пустая, а отладчик и вовсе показал Запрос.СчетДок не "60.01", а "2U.  3 ", т.е. внутренний код из базы.

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

Проверь типзначениястр(счетдок).
Убери мешащее условия. Результат запроса выгрузи в таблицу значений проверь, какой тип значения у счёт док.

(0) Задам возможно глупый вопрос. Просто очень похоже, что это Ваш код:
Сч60 = "60.01";
Вы текстовую строку в параметр передаете?

Ну и проверить, у тебя 3 условия, они все соединяются по "И" и если добавляешь условие и выборка пустая, если всё нормально, значит, 3 раза И получается ложь. Проверяй, есть ли у тебя Массивы данных, удовлетворяющие трём и.

Блин. Начисто забыл 7.7

|Условие (Валюта = Константа.ОсновнаяВалюта);
|Условие (Назначение = ТекНазначение);

Да. Попробуйте это закомментировать.

(1)
типзначениястр(счетдок) во всём запросе = "счет", как для нужных счетов, так и для ненужных.

>>>Я бы так не в жизнь бы не написал тёк назначения. Ну, если поискал его, я бы написал проверить, если найден, то дальше, не найден всё алярм

Я так и не пишу обычно, это написал просто для примера, чтобы понять, с одним реквизитом отбора такая ерунда или и с другими тоже. Но нет, проблема только со счётом, с константой и элементом справочника проблем нет.

(2)
Сначала передавал значение типа "Счет". Когда понял, что не отрабатывает, пробовал передавать строкой.

(3)
массивы есть конечно же, проверил 100 раз.

Убери все условия, оставь только по счету. И танцуй отсюда.

(5)
Даже если оставить в запросе одно условие
|Условие (СчетДок = Сч60);
то выборка сразу пустая, остальные условия добавлялись позже, просто чтобы попытаться локализовать проблему.

В конфигураторе счетдок какой тип у реквизита задан?

Черный запрос - зло

Делайте лучше или перебором, или (если элементов много и время обработки критично) - через прямые запросы

(11)
<<Счет>>

А что за 60.01 в семерке ? Такие счета в восьмерке?

(13)
Можно конечно все перебрать построчно, записать в ТЗ и фильтровать уже там, но будет сильно дольше и больше кода, плюс сразу теряем все красивые группировки с подбитыми суммами.

(15)
Расчеты с поставщиками и подрядчиками (Контрагенты / Договора)

(17)у Вас самописная ? в типовых счет 60.1, а не 60.01
Так то я в курсе что это за счет

(18)
Полная самописка.

(19)но все таки гляньте, вдруг 60.1

(20)
Да не, всё не настолько просто :)

Поди есть реквизит на форме с идентификатором Сч60?..да?

(11)
Знаете, что самое любопытное: если в конфигураторе поменять тип реквизита со "<<Счет>>" на "Счет.Основной", то условие запроса начинает отрабатывать абсолютно корректно.
Однако при сохранении конфигуратор ругается на некую частичную потерю данных.
Кто-то может объяснить этот бред ?

(22)
Нет такого реквизита + сам запрос расположен во внешнем отчёте, с документом он никак не пересекается.

Посмотрите в документе какой тип у СчетКредит и посмотрите в отладчике что такое Сч60

(23)он и должен быть счет основной. Бред похоже в другом месте ) Вы разработчик этой самописки ?)

(25)
Везде тип = "Счет".

(23) почему бред?..в конфе может быть куча планов счетов

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

И тебе надо не счет по коду, а для конкретного плана счетов счет по коду

(28)
В конкретно этой конфе план счетов один.
Но даже если написать
Сч60 = СчетПоКоду("60.01",ПланыСчетов.Основной)
то проблема остаётся.

Поставь в СчетПоКоду второй параметр

(31) тогда тест на вшивость:
Вася = СчетПоКоду("60.01",ПланыСчетов.Основной);
Сообщить(ТипЗначенияСтр(Вася));
|Условие (ТвойСчет = Вася);

(33)
Вася = СчетПоКоду("60.01",ПланыСчетов.Основной);
Сообщить(ТипЗначенияСтр(Вася));
Вася = СчетПоКоду("60.01");
Сообщить(ТипЗначенияСтр(Вася));

Результат:
Счет
Счет

а попробуй такое условие
|Условие (СчетДок В Сч60);
И еще вытащи на форму реквизит типа Счет и заполни там.

(34)
Выборка пустая при обоих Василиях.

(36) Значит, в выбранном периоде нет документов с таким счетом.

ТипЗначенияСтр недостаточно. Это всегда счет

(35)
Безрезультатно в обоих случаях.

(37)
Увы, есть, и их тысячи. Если бы их не было, то и при Счет.Основной выборка бы не работала.

Надо еще и Вид()
То что он Счет ясно и ежу

Ну, хотя бы покажи, что возвращает
|СчетДок = Документ.ПоступлениеТМЦ.СчетКредит.Код;
Это..при отсутствии условия на счет

(42)
См. (0), я там писал
возвращает "2U.  3 ", т.е. внутренний код из базы.

(41)
Вася = СчетПоКоду("60.01",ПланыСчетов.Основной);
Сообщить(Вася.Вид());
Вася = СчетПоКоду("60.01");
Сообщить(Вася.Вид());

Результат:
Основной
Основной

(43) формат базы какой хоть? Sql/dbf

(43) а СчетКредит.Наименование что возвращает?

(45)
SQL 2008, БД в режиме SQL 2000.

(46)
|СчетДокНаим = Документ.ПоступлениеТМЦ.СчетКредит.Наименование;

отладчик вернул
"2U    3N                                                    "

(47)
Запрос.ВключитьSql(0);

>>>БД в режиме SQL 2000  

это вообще за гранью добра, при условии, что клюшки и на 2022 скуле работают, без режима совместимости

(49)
Работает :)
Бред №2 :)))

(50)
Уже не вспомню, почему так сделано, но что-то видимо не работало из сторонних DLL в режиме SQL выше 2000.

Тогда что посоветуете: оставить Запрос.ВключитьSql(0) или лучше в самом документе поменять тип реквизита со "<<Счет>>" на "Счет.Основной" ?

Во втором случае немного смущает сообщение о частичной потере данных, хотя и неясно, чему там теряться при одном плане счетов.

(48) таким образом, и счёт и наименование являются уникальными, но зашифрованными?  Так кто ж тебе мешает отобрать не по "60.01" а по "2U    3N                                                    " ?

(54)
Во-первых, я не уверен, что эти UID-ы не сменятся при каком-нибудь пересчёте итогов или выгрузке/загрузке БД.

Во-вторых, мне нужна фильтрация по целому списку счетов, а такие UID-ы в коде будут выглядеть как минимум странно.

(53) посоветую: Переписать на прямой запрос, и забыть черные запросы как страшный сон.

(56)
Увы, не владею такой техникой боя.

(53) прямой запрос вестимо. Ибо отключив sql , ваш запрос сильно того, замедлится.
В дбф такой проблемы нет, а в sql многие чОрные запросы не работают как нннадо, то же вхождение в список и т.д.

(55) Во-первых, ты можешь изучить или протестировать, в каких случаях меняется уид. Во-вторых, тебе шашечки - или ехать?
Тем более что (57)

Ну, как временная мера, попробовать в копии счет на счет.основной поправить в доке

(57) даже понятно почему не прижился у нас карате - русский никогда не бил от бедра, а рубил сплеча... ;-)

Ну так в итоге что?
Галактика волнуется...

(62) см (51)