1с 8.3 отчет скд период. Создаем отчет с заданной периодичностью на скд

В этой статье рассмотрены некоторые особенности настройки периода при использовании Системы Компоновки Данных (СКД), проблемы которые возникают из-за различия в понятии периода между рядовым пользователем и системой 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При создании отчетов на СКД часто возникает необходимость вывести на форму отчета выбор периода, причем, чтобы не нужно было забивать даты вручную, а выбрать из списка стандартных периодов, таких как: «Года», «Месяц», «Неделя» и т.д. Для параметров типа Дата можно указать только «Начало этого года, месяца и т.д.», но «Окончание» не предусмотрено.

Дело в том, из типов данных доступен только тип «Стандартная дата начала», а хочется еще «Стандартная дата окончания».

Существует метод как это обойти.

1. Создадим новый Параметр, назовем его «Период»
2. Установим для этого параметра тип «Стандартный период»
3. В поле «Выражение» параметров «НачалоПериода» и «КонецПериода», которые используются в запросе, установим выражения «&Период.ДатаНачала» и «&Период.ДатаОкончания» соответственно.

Но существует небольшая тонкость. Если мы используем в запросе виртуальные таблицы, то, скорее всего, отчет перестанет работать и будет выдаваться сообщение об ошибке типа «Ошибка обработки представления, несоответствие типов, параметр номер...».

Чтобы этого избежать, нужно убрать все параметры виртуальных таблиц.

И добавить их к таблицам на закладке «Компоновка данных».

Для того, чтобы параметны отображались в быстрых настройках отчета, включим соответствующий флаг для параметров отчета.

Теперь выбор периода на форме отчета выглядит так.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доброго времени суток, уважаемые читатели блога сайт! В прошлой статье мы узнали, и для чего эти роли нужны. А сегодня во второй из этой серии статей, мы рассмотрим настройку роли со свойством «Период» , а также рассмотрим примеры заполнения этих ролей. По полю с ролью «Период» рассчитывается остаток. Также, как и по полю с ролью «Измерение», о котором мы поговорим в другой раз. Итак, начнем!

Создадим новый отчет:

1. В Конфигураторе выберем пункт меню «Файл» — «Новый» — «Внешний отчет».
2. Нажмем на кнопку «Открыть схему компоновки данных». В открывшемся диалоге нажмем кнопку «Готово».
3. Теперь создадим , который обращается к виртуальной таблице «РегистрыНакопления».
4. Нажмем правой кнопкой мыши на на узле «НаборыДанных» и выберем строчку «Добавить набор данных — Запрос».
5. Теперь нажмем на кнопку «Конструктор запроса». Выберем регистр накопления «ТоварыНаСкладахОстаткиИОбороты» (конфигурация УТП).
6. Откроем диалог «Параметры виртуальной таблицы» и укажем, что будет использоваться периодичность «Авто», то есть можно будет указывать несколько периодов.

Теперь настроим выходные поля. Пусть это будут следующие поля: «Регистратор», «ПериодМесяц», «Номенклатура», «Качество» и информация по остаткам. Добавление поля осуществляется двойным нажатием левой кнопки мыши на нужном поле или при помощи кнопки «>». После добавления полей нажмем кнопку «ОК».

Обратите внимание, что для некоторых полей автоматом настроилась роль со свойством «Период».

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

Таким образом должны быть пронумерованы поля, которые встречаются в нашем запросе. Заметьте, что у нас есть два поля периода — «Регистратор» и «ПериодМесяц». Младшим полем является «Регистратор» ему присвоена единица, а старшим полем является «ПериодМесяц» ему присвоена двойка. Более подробно о мы рассмотрим в следующей статье.

Настроим наш отчет:

1. Перейдем на закладку «Ресурсы» и определим ресурсы нашего отчета.
2. Нажмем на кнопку «>>», чтобы выбрать все поля для ресурсов.
3. Теперь перейдем на закладку «Настройки» и создадим настройку в виде списка.
4. Нажмем на кнопку «Конструктор настроек компоновки данных» (кнопка в виде волшебной палочки).
5. Тип отчета: «Список». Нажмем кнопку «Далее».
6. Настроим выходные поля, нажав на кнопку «>>». Упорядочим их так: «ПериодМесяц», «Номенклатура», «Качество», «Регистратор».
7. Нажмем кнопку «Далее» и настроим группировку. Группировку настроим в следующем порядке: «ПериодМесяц», «Номенклатура», «Качество». Группировка «Регистратор» будет выводиться в виде детальных записей.
8. Нажмем кнопку «ОК».

Откроем наш отчет . Если мы выполним этот отчет, то увидим некоторые особенности при получении остатков. Если внимательно присмотреться к результату отчета, то сразу заметно несколько ошибок. В частности, почему-то в самом начале периода деятельности компании существует начальный остаток.

И это ошибка связана с особенностью получать остатки по регистратору. Чтобы эти остатки выводились корректно, необходимо добавить еще одно поле в выходные поля запроса это поле «ПериодСекунда». Для добавления поля «ПериодСекунда» откроем отчет в Конфигураторе, нажмем на кнопку «Открыть схему компоновки данных». Теперь нажмем на кнопку «Конструктор запроса» и добавим «ПериодСекунда». В этом случае поле «Регистратор» у нас останется первым полем периода, «ПериодСекунда» будет вторым, а «ПериодМесяц» будет третьим.

Для чего нужна секунда? Система компоновки данных вычисляет остатки расчетным путем, и для того чтобы однозначно определить положение регистратора на временной оси самой ссылки на регистратор недостаточно, нужна еще и секунда, то есть дата этого регистратора, и тогда система компоновки сможет расчетным путем получить верный остаток. Если укажем правильный порядок полей и сформируем отчет заново, то получим:

Сейчас остатка на начало деятельности по номенклатуре «Плинтус» уже нет. Далее на следующий период он совпадает с конечным остатком, то есть мы видим действительно правильный результат. Пример отчета вы можете скачать по ссылке ниже. Понравилась ли вам статья? Что можно изменить, что добавить? Не стесняйтесь делиться об этом в комментариях!

В конце статьи хочу посоветовать вам бесплатный от Сотникова Анатолия. Это курс от опытного программиста. Он на отдельной базе покажет вам, как строить отчеты в СКД. Вам только нужно внимательно слушать и запоминать! Вы получите ответы на такие вопросы:

• Как создать простой отчет в виде списка?
• Для чего нужны колонки Поле, Путь и Заголовок на закладке «Поля»?
• Какие существуют ограничения для полей компоновки?
• Как правильно настраивать роли?
• Какие существуют роли для полей компоновки?
• Где найти закладку компоновка данных в запросе?
• Как настраивать параметры в СКД?
• Дальше еще интереснее...

Наверное, не стоит самому стараться бороздить интернет в поисках нужной информации? Тем более все готово для применения. Только начните! Все подробности о том, что есть в бесплатных видеоуроках

Вот один из уроков о закладке компоновки данных в запросе: