привет,
Есть задача справочник номенклатура, в нем есть реквизит "старая группа",
Есть группа номенклатуры "Архив"
по мере необходимости туда попадают ненужные по мнению рук. элементы номенклатуры, с записью в реквизит "СтараяГруппа" прежнего родителя группы.

Задача в том чтобы при формировании отчета и отбора по номенлатуре (в группе или списке групп) в отчет попадали позиции если в отборе указать и те которые соответсвуют "Старой группе".

спасибо!

ИЛИ?

(1)  предлагаешь использовать параметры? думал уже, не сосвем хорошо, при компановке анализ полей отбора, формирование параметров и объеденение с основной табл. ? чет не особо красиво.

На вкладке компоновка попробуй указать поле отбора СтараяГруппа, псевдоним Номенклатура

(2) я бы не ипал мозг и делал группу ИЛИ при отборе научатся с третьего раза

(2) параметры тут ни причем, ну вот ни разу. Стандартный отбор.

(3) пробовал, компоновка отбором их отсекает

(4) ), Люди перешли с 77, и вид настроек компановки вызывает столбняк, думаю это пока временное явление, прогресс необратим, но все таки.
в архиве все лежит в куче поэтому вспомнить что там было не очень удобно. отсюда и задача.

(0) Вроде, получилось. Так:

1. Делаем ВТ, в которую объединением помещаем Номенклатура.Ссылка
И
Номенклатура.СтараяГруппа
На вкладке компоновка устанавливаем поле условие для обоих запросов объединения. Я назвал его НоменклатураОтбор
2. Делаем выборку, которую хотим, соединяем её по номенклатуре с нашей ВТ.
3. В отчете Отбор используем по полю НоменклатураОтбор. По полю номенклатура отбор можно отключить
4. ...
5. PROFIT!

Если лень писать свой собственный интерфейс для удобной настройки отборов (что для пользователей, перешедших с 77 было бы крайне нужно). То можно сделать такой финт - перехватить кнопку формирования отчета (если это ещё не сделано).  И самостоятельно кодом перед формированием отчета найти стандартный отбор по номенклатуре в настройках схемы и заменить его на связку ИЛИ (два отбора: стандартный по ссылке и ещё один по реквизиту "СтаряГруппа"). Затем сформировать отчет, и снова кодом вернуть исходную схему настроек (можно просто сохранить её в переменную перед изменением, в конце загрузить обратно.

+(8)
http://gyazo.com/493ce26505d5a6b3988d3cb4d166d184
http://gyazo.com/98a004094c8fbdca6803712f153b9743
http://gyazo.com/4224e8d2e400d1eb337d7fb894e340f3
http://gyazo.com/259eb70a57b3ee82a9a7608551bfcc6f

Ещё один вариант (скорее всего именно его я бы использовал)
В обычных элемента справочника номенклатуры (не архивных) я бы тоже заполнял реквизит "СтараяГруппа", просто ссылкой на их родителя. И в отборе использовал чисто отбор по данному реквизиту - нужно его только грамотно назвать в СКД, чтобы подходило для общего понимания по какому критерию данное условие отбора.

При таком подходе в СКД можно и при выводе иерархию строить по своему реквизиту "СтаряГруппа".

Всё просто, понятно и эффективно.

(11)Нет, пожалуй предыдущий вариант я не использовал бы ;) Так как использую другой подход скрытия старых элементов.
Я не люблю группу "Архив" (хотя его всё де иногда использую, но как раз именно, чтобы эти элементы не попадали в стандартные отборы отчетов). А для скрытия старых элементов я использую следующий подход:
В самих элементах размещаю два реквизита даты: ДатаНачала и ДатаОкончания. Даты заполняются при создании нового элемента справочника (дата окончания  - ставится далеко в будущем, дата начала - берётся из специальных настроек). Далее возможны три пути (мы сейчас потихоньку переходим от первого к второму и далее, возможно, к третьему):
1. В формах списка справочника делаем преднастроенный (кодом) отбор - отобрать элементы где ДатаНачала меньшеИлиРавна текущей дате просмотра (это или текущая рабочая дата или дата получаемая из вызывающего кода, например дата документа). А ДатаОкончания БольшеИлиРавна это  текущей дате. И всё - нужные элементы отобраны, остальные скрыт. У этго способа есть три важных недостатка: группы не скрываются; нужно писать код в формах списка; в запросах нужно допиливать использование такого отбора. Но данный подход весьма универсален и прост.
2. Развитие 1-го варианта приводит нас к использованию РЛС -  те же реквизиты, но отбор уже идёт в условиях доступа ролей Record Level Security. Что эффективнее обычных отборов. У данного подхода есть существенные плюсы - корректно работает и ввод по строке, скрытие недоступных групп, не нужно переделывать запросы (ну почти не нужно - это уже вопрос к из грамотному исходному составлению, т.е. с учетом того, что может быть использован РЛС).
3. Это дальнешее "усовершенствоание" первых двух вариантов. Вынос реквизитов ДатаНачала и ДатаОкончания из структуры справочника в отдельный регистр сведений и привязка к ним в условиях РЛС отдельным запросом. Этот подход годится и для 1-го случая, без РЛС, но тогда придётся переписывать форму списка справочника - на работу со списком, получаемым из регистра сведений - что несколько не удобно.

Ну, пожалуй, добавлю ещё, что если говорить об управляемом приложении - то там есть динамические списки - там можно 3-тий вариант реализовать меньшей кровью и без РЛС. Хотя, на мой взгляд - умеренное использование РЛС (при правильной настройке и несложных условиях без массовых пересечений по ролям) - это очень большое благо.

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