Создадим отчет с одни набором данных запрос:

ВЫБРАТЬ
    ТоварыНаСкладахОстатки.Склад,
    ТоварыНаСкладахОстатки.Номенклатура,
    ТоварыНаСкладахОстатки.КоличествоОстаток
ИЗ
    РегистрНакопления.ТоварыНаСкладах.Остатки(&МояДата, )
                               КАК ТоварыНаСкладахОстатки
 
Создадим отчет с одни набором данных запрос: ВЫБРАТЬ ТоварыНаСкладахОстатки.Склад, ТоварыНаСкладахОстатки.Номенклатура, ТоварыНаСкладахОстатки.КоличествоОстаток ИЗ РегистрНакопления.ТоварыНаСкладах.Остатки(&МояДата, )  КАК ТоварыНаСкладахОстатки Теперь перейдем на вкладку параметры и увидим что система, помимо нашего параметра &МояДата создала еще и параметр &Период. Для того, чтобы наглядно наблюдать за периодами, создадим основную форму отчета и поместим на нее табличное поле с данными: КомпоновщикНастроек.Настройки.ПараметрыДанных Сохраним отчет и откроем его в предприятии. В табличном поле с параметры отображается только параметр &Период: Соответственно, любое изменение этого параметра не даст нужного результата. Почему недоступен параметр &МояДата? Конечно же потому что на вкладке параметры у него установлена галку Ограничение доступности. Снимаем галку. Теперь в доступных параметрах видим оба. Только при формировании отчета увидим, что отчет реагирует на параметр &Период, а не на &МояДата. В данном примере самое простое переименовать в запросе параметр &МояДата на &Период и добиться нужного результата. Но может быть у Вас запрос, в котором уже использовался параметр &Период, или Ваши религиозные взгляды не разрешают Вам использовать этот параметр, в любом случае можно решить проблему так: ВЫБРАТЬ ТоварыНаСкладахОстатки.Склад, ТоварыНаСкладахОстатки.Номенклатура, ТоварыНаСкладахОстатки.КоличествоОстаток ИЗ РегистрНакопления.ТоварыНаСкладах.Остатки({&МояДата}, ) КАК ТоварыНаСкладахОстатки UPD от пользователя Boo: Главная проблема при использовании «стандартных» (добавляемых системой) параметров в том что при использовании в отчете нескольких виртуальных таблиц, в случае определения этого параметра, его значение будет использоваться во всех остальных случаях взамен «собственных». Приведу пример: ВЫБРАТЬ РаботникиСП.Сотрудник, РаботникиСП.ПричинаИзмененияСостояния, РаботникиСП.Период, РаботникиСПДругаяДата.Период КАК Период2, РаботникиСПДругаяДата.ПричинаИзмененияСостояния КАК ПричинаИзмененияСостояния2 ИЗ РегистрСведений.РаботникиОрганизаций.СрезПоследних(&Период, Сотрудник = &Сотрудник) КАК РаботникиСП ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.РаботникиОрганизаций.СрезПоследних(&ДругаяДата, ) КАК РаботникиСПДругаяДата ПО РаботникиСП.Сотрудник = РаботникиСПДругаяДата.Сотрудник Во втором подзапросе, в качестве параметра даты среза будет использовано значение «стандартного» параметра ПЕРИОД, а не значение ДругаяДата. Данный «глюк» будет наблюдаться даже в том случае если второй подзапрос вывести во второй набор данных и связать уже средствами СКД. Вариант с использованием во втором запросе ваыражения типа «ДОБАВИТЬКДАТЕ(&Период, МЕСЯЦ, -1) » тоже не сработает, месяц не вычтется. А вот переименование в запросе параметра «Период» в, например, «ПерваяДата», решает эту проблему. Кстати, точно такая же проблема наблюдается с виртуальными таблицами регистров накопления и бухгалтерии, используемыми для получения, например, оборотов. Там система добавляет параметры «НачалоПериода» и «КонецПериода». Так что в случае запросов даже чуть повышенной сложности, есть смысл выключать доступность и использование «стандартных периодов»....