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

20.02.2024

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Некоторые особенности настройки периода в СКД.

Большинство отчетов, которые разрабатываются при помощи Системы компоновки Данных (СКД) требуют от пользователя ввода периода, за который будет построен отчет.

Как правило, в СКД ввод периода организован через параметры, с помощью следующей конструкции см. Этот способ ввода периода считается "классическим", он описан в статье на ИТС и другой литературе, посвященной разработке в 1С, поэтому возьмём его за основу. Рассмотрим в качестве примера простой запрос, получающий все документы РеализацияТоваровУслуг за заданный период см.

При использовании этого отчета пользователь задает период через параметры см. Вроде бы все корректно…, НО есть маленькая проблема:

Все дело в том, что подавляющее большинство пользователей «понимают» период не так как его «понимает» 1С, примеры:

С точки зрения пользователя период не задан, то есть НЕ ОГРАНИЧЕН, то есть в отчет должны попасть ВСЕ документы без ограничения по дате.

«С точки зрения» системы 1С параметр-период задан и … обе его границы равны 01.01.0001 и в отчет, попадут только документы с пустой датой, что на практике означает, не попадет ни одного документа.

С точки зрения пользователя в отчет должны попасть все документы начиная с даты 28.01.2010.

«С точки зрения» 1С период 28.01.2010 - 01.01.0001 вызовет исключение.

Можно конечно попытаться объяснить пользователю, почему отчет не выводит те документы, которые он ожидает увидеть и как период представляется с "точки зрения" 1С, но неблагодарное это дело, да и неправильное. Хорошая программа должна быть, прежде всего, удобна пользователю, потому как программа существует для пользователя, а не наоборот, посему придется «научить» 1С понимать период так как его понимает пользователь, а именно:

1). НачалоПериода и ОкончаниеПериода не заданы -> все документы.

2). Задано только НачалоПериода -> все документы начиная с НачалаПериода

3). Кроме того будем проверять что бы ОкончаниеПериода >= НачалоПериода, и если это не выполняется то будем считать что ОкончаниеПериода не задано, т.е. 2).

Исходя из всего вышесказанного выражение для параметра ДатаОкончания:

КОГДА &Период.ДатаОкончания=ДАТАВРЕМЯ(1,1,1)

ТОГДА ДАТАВРЕМЯ(3999,12,31)

КОГДА &Период.ДатаОкончания<&Период.ДатаНачала

ТОГДА ДАТАВРЕМЯ(3999,12,31) ДАТАВРЕМЯ(3999,12,31,23,59,59)

&Период.ДатаОкончания

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

Примечание: данный механизм установки параметров предназначен для старых платформ 1С 8.1 и 8.2(и конфигураций работающих под их управлением), в более старших версиях платформы 1С имеются встроенные механизмы для контроля незаполненных параметров и прибегать к механизму описанному в данной статье нет никакой необходимости, кроме того на некоторых версиях платформы 1С возможны ошибки и некорректная работа.