Итак, снова поднимаю тему про параметры-отборы в виртуальных таблицах и их смысл.
Прочитав глас одинокого вопиющего Гения1С в http://www.forum.mista.ru/topic.php?id=282346&page=1, а также недовыясненные вопросы в http://www.forum.mista.ru/topic.php?id=432055, снова вопрошаю защитников отбора в виртуальной таблице:
Как использовать виртуальную таблицу (а зачем её вообще использовать, нельзя - не используй, спросите вы? А для чего еще, если не для быстроты запроса к "базовому" регистру этой таблицы), если нужен отбор по записи и - самое важное! - по ссылкам-реквизитам этой записи (пусть это будет склад из документа РТиУ, который в свою очередь, является документом-регистратором в РН Продажи (да даже неважно, в каком).
Непонятные отсылки к Книга знаний: v8: Виртуальные таблицы запросов (а что там сказано про параметры ВТ вообще и отборы в частности?) и к книге "Проф.разработка 1С8" (а нет там даже строчечки о том, что в отборах ВТ к РН НЕЛЬЗЯ использовать реквизиты и прочее, а только ИЗМЕРЕНИЯ самого РН - стр. 231 "Получение данных из РН и применение отборов к РН") - непонятны в силу "а к чему они были приведены?", и поэтому прошу их не давать.
Вот значит, что получается: документ как регистратор является костяком всего регистра (и должен являться ведущим и для производного от регистра - виртуальной таблицы с её итогами; ведущим - т.е. уж по нему-то я должен получать полную информацию при любом виде запроса к регистру), а отбор по его реквизиту я могу сделать только обыкновенным способом - через ГДЕ уже после формирования ВТ (тогда зачем она вообще нужна, если я могу и сам регистр запросить с точно таким же успехом).
Для наглядности, о чем речь - пример:

ВЫБРАТЬ
  РеализацияТоваровУслуг.Ссылка КАК РТиУСсылка,
  СУММА(Продажи.СуммаПродажОборот) КАК СуммаПродажОборот    
ИЗ
  РегистрНакопления.СуммаПродажОборот.Обороты(&НачПериода, &КонПериода, Регистратор, ) КАК СуммаПродажиОбороты
      ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
      ПО СуммаПродажОборот.Регистратор = РеализацияТоваровУслуг.Ссылка
ГДЕ РеализацияТоваровУслуг.Контрагент.Адрес = &Адрес

ИТОГИ
  СУММА(СуммаВзаиморасчетовОборот)
ПО
  ОБЩИЕ

И полностью согласен с Гением1С - зачем вообще нужен параметр-отбор в ВТ (да и само понятие ВТ - если смотреть на это с точки зрения требования быстродействия с одной стороны, и невозможности в данном случае пользоваться этим быстродействием - с другой), если я не могу прописать в её отборе:
РегистрНакопления.СуммаПродажОборот.Обороты(&НачПериода, &КонПериода, Регистратор, Регистратор.Контрагент.Адрес = &Адрес) КАК СуммаПродажиОбороты
- и только потому, что Регистратор - не ИЗМЕРЕНИЕ регистра накопления Продажи, а "всего лишь" РЕГИСТРАТОР! :)

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

(14) Лови гранату:

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

Куда надо пеоместить условие?

Ибо так в разы быстрее. А если еще прикрутить умеючи временные таблицы , то ух как хорошо.

глупый вопрос теоретика, который сам ни разу не пробовал

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

(36) >> Итак, нечто, громко названное "механизм виртуальных таблиц", оказалось на деле просто сверткой по измерениям

а мужики то не знают...

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

Как в требованиях к спецу было сказано, так и использую

всё не читал. Но голос свой оставлю.

Так быстрее!

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

Основное назначение ВТ  - быстрое получение остатков/оборотов по набору измерений за счет использования агрегатов. Сам по себе механизм виртуальных таблиц никакого быстродействия не несет. Обращение к данным ускоряется только за счет использования агрегатов.

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

Если же по условиям задачи необходимо получать обороты в разрезе регистраторов.  Добавить новое измерение. В типовых именно так и сделано  - измерение "Документ продажи" в РН "Продажи". Хотя эффективность данного подхода сомнительна.

В общем случае для понимания сути и назначения механизмов было бы неплохо прочитать про структуру хранения данных в РН в книжке  "Профессиональная разработка в системе 1С:Предприятие 8" http://v8.1c.ru/metod/books/book.jsp?id=63.

Так же неплохо было бы глянуть  физическую структуру таблиц РН в SQL.  А если интересует физический механизм работы ВТ то с помощью профайлера разобрать план запроса и текст запроса в РН.

(45) А какие еще измерения в регистре Продажи? Нельзя найти всех контрагентов с нужным адресом, а в параметры виртуальной таблицы передать список контрагентов?

// Каждый механизм для своего, и для чего ВТ "распиарен" - он прекрасно справляется. Используйте вещи по своему назначению :)