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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак, начнем.

Для простоты понимая пример будем строить на одном простом оборотном регистре накопления.

В моем случае это регистр накопления "Незавершенное производство бухгалтерский учет".

Его параметры для примера укажем жестко (не через мягкое накладывание параметров на СКД):

Обратим внимание, периодичность виртуальной таблицы - "Запись".

Но, как было замечаено выше, период нам нужен в разрезе периодичности, поэтому поле "Период" я предлагаю вычислить следующим путем (несовсем красиво, но лучше вариантов я не видел):

Как видно из скриншота, в запрос передается параметр, который пользователь указывает на форме: Значение перечисления "Периодичность" - данное перечисление есть практически во всех типовых решениях.

Его доустпные типы укажем на вкладке "Параметры":

Этой настройкой мы форматируем наш период, чтобы все было красиво и радовало глаз)

Вот, собственно, сами форматы:

Месяц: ДФ="ММММ гггг "г.""

День: ДФ = дд.ММ.гггг

Неделя: ДФ = ""Неделя с" дд.ММ.гггг "

Квартал: ДФ = "к "квартал" гггг "г.""

Год: ДФ = "гггг "г.""

Декада: ДФ = ""Декада с" дд.ММ.гггг "

Полугодие: ДФ = ""Полугодие с" дд.ММ.гггг"

Вот и все. На выходе имеем замечательную картину:

В этой статье рассмотрены некоторые особенности настройки периода при использовании Системы Компоновки Данных (СКД), проблемы которые возникают из-за различия в понятии периода между рядовым пользователем и системой 1С, а так же предложены пути их решения.
Большинство отчетов, которые разрабатываются при помощи Системы компоновки Данных (СКД) требуют от пользователя ввода периода, за который будет построен отчет. Как правило, в СКД ввод периода организован через параметры, с помощью следующей конструкции см. Рис.1 Этот способ ввода периода считается “классическим”, он описан в статье на ИТС и другой литературе, посвященной разработке в 1С, поэтому возьмём его за основу. Рассмотрим в качестве примера простой запрос, получающий все документы РеализацияТоваровУслуг за заданный период см. Рис.2 При использовании этого отчета пользователь задает период через параметры см. Рис.3 Вроде бы все корректно…, НО есть маленькая проблема:

Все дело в том, что подавляющее большинство пользователей «понимают» период не так как его «понимает» 1С, примеры:
1). Рассмотрим Рис.3
С точки зрения пользователя период не задан, то есть НЕ ОГРАНИЧЕН, то есть в отчет должны попасть ВСЕ документы без ограничения по дате.
«С точки зрения» системы 1С параметр-период задан и … обе его границы равны 01.01.0001 и в отчет, попадут только документы с пустой датой, что на практике означает, не попадет ни одного документа.
2). Рассмотрим Рис.4
С точки зрения пользователя в отчет должны попасть все документы начиная с даты 28.01.2010.
«С точки зрения» 1С период 28.01.2010 – 01.01.0001 вызовет исключение.

Можно конечно попытаться объяснить пользователю, почему отчет не выводит те документы, которые он ожидает увидеть и как период представляется с “точки зрения” 1С, но неблагодарное это дело, да и неправильное. Хорошая программа должна быть, прежде всего, удобна пользователю, потому как программа существует для пользователя, а не наоборот, посему придется «научить» 1С понимать период так как его понимает пользователь, а именно:
1). НачалоПериода и ОкончаниеПериода не заданы -> все документы.
2). Задано только НачалоПериода –> все документы начиная с НачалаПериода
3). Кроме того будем проверять что бы ОкончаниеПериода >= НачалоПериода, и если это не выполняется то будем считать что ОкончаниеПериода не задано, т.е. 2).
Исходя из всего вышесказанного выражение для параметра ДатаОкончания будет иметь следующий вид:

ВЫБОР КОГДА &Период.ДатаОкончания=ДАТАВРЕМЯ(1,1,1) ТОГДА ДАТАВРЕМЯ(3999,12,31,23,59,59) ИНАЧЕ ВЫБОР КОГДА &Период.ДатаОкончания<&Период.ДатаНачала ТОГДА ДАТАВРЕМЯ(3999,12,31,23,59,59) ИНАЧЕ &Период.ДатаОкончания КОНЕЦ КОНЕЦ

Окончательный вид нашей конструкции выбора периода представлен на Рис.5