Стандартный параметр &Период и проблемы в использовании

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

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

Теперь перейдем на вкладку параметры и увидим что система, помимо нашего параметра &МояДата создала еще и параметр &Период.
Для того, чтобы наглядно наблюдать за периодами, создадим основную форму отчета и поместим на нее табличное поле с данными: КомпоновщикНастроек.Настройки.ПараметрыДанных

Сохраним отчет и откроем его в предприятии. В табличном поле с параметры отображается только параметр &Период:

Соответственно, любое изменение этого параметра не даст нужного результата.

Почему недоступен параметр &МояДата? Конечно же потому что на вкладке параметры у него установлена галку Ограничение доступности.

Снимаем галку. Теперь в доступных параметрах видим оба. Только при формировании отчета увидим, что отчет реагирует на параметр &Период, а не на &МояДата.

В данном примере самое простое переименовать в запросе параметр &МояДата на &Период и добиться нужного результата. Но может быть у Вас запрос, в котором уже использовался параметр &Период, или Ваши религиозные взгляды не разрешают Вам использовать этот параметр, в любом случае можно решить проблему так:

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

UPD от пользователя Boo:

Главная проблема при использовании «стандартных» (добавляемых системой) параметров в том что при использовании в отчете нескольких виртуальных таблиц, в случае определения этого параметра, его значение будет использоваться во всех остальных случаях взамен «собственных».

Приведу пример:

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

Во втором подзапросе, в качестве параметра даты среза будет использовано значение «стандартного» параметра ПЕРИОД, а не значение ДругаяДата.

Данный «глюк» будет наблюдаться даже в том случае если второй подзапрос вывести во второй набор данных и связать уже средствами СКД. Вариант с использованием во втором запросе ваыражения типа «ДОБАВИТЬКДАТЕ(&Период, МЕСЯЦ, -1) » тоже не сработает, месяц не вычтется. А вот переименование в запросе параметра «Период» в, например, «ПерваяДата», решает эту проблему.

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