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

Отзывов (4)FavoriteLoadingВ закладки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

google.com bobrdobr.ru del.icio.us technorati.com linkstore.ru news2.ru rumarkz.ru memori.ru moemesto.ru

4 Коммент.

  1. Есть одно уточнение: Реагирует на &Период при одновременном использовании с &МояДата…А то всю голову сломал – по отдельности нормально реагирует…

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

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

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

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

Оставить комментарий

RSSКомментарии в RSS

Авторизация

Логин:
Пароль:
Регистрация

Архивы

Закладки

  • Your favorites will be here.