Заметки по SQL: Запрос, получающий изменения ресурса в регистрах сведений по датам изменения за период

20.11.19

Разработка - Запросы

В статье описан метод получения изменения ресурса регистра сведений по датам изменения, построенный на основе запроса "Сумма накоплением".
          1. Введение

    Хорошо известен запрос получающий сумму накоплением. Примером такого запроса на классическом SQL, получающего конечный остаток номенклатуры с периодичностью "День" из регистра ТоварыНаСкладах конфигурации "Управление торговлей 11" может послужить публикация "Заметки по SQL: Генерация ряда дат и данные из периодических регистров на каждый день", раздел 3. "Остатки на каждый день". Код упрошенного запроса приведен ниже.

 
 Код запроса остатков номенклатуры на классическом SQL по периоду изменения день

      Аналогичный результат можно получить используя виртуальную таблицу остатки и обороты

 
  Код запроса остатков номенклатуры с использованием виртуальной таблицы остатки и обороты

    Естественно, сразу возникает вопрос а зачем это нужно, если виртуальная таблица остатки и обороты получающая аналогичный результат. Все это так, но внимательный читатель заметил одно очень интересное поле в первом запросе, которое называется "НомерВГруппе". Выгрузим запрос в таблицу.

Как видно из "скриншота", поле "НомерВГруппе" имеет прямую зависимость от поля "Период". Фактически даты в периоде имеют нумерацию полем "НомерВГруппе" по возрастанию. Это свойство и будет в дальнейшем использовано для построения запроса вычисляющего изменение цены.

 
 Небольшой комментарий по сравнению быстродействия запросов получения остатков номенклатуры.
        2. Построение запроса "Динамика изменения цен за период".

     Запрос использовался в отчете публикации "Продажи в динамике изменения цен номенклатуры за период" . 

     Подготовим данные. Поскольку конфигурация УТ11, позволяет вводить цены по номенклатуре документом "Установка цен номенклатуры" за один день неограниченное количество раз, то нам, для корректной работы запроса, необходимо получить последнюю цену установленную за день.  Регистр сведений "ЦеныНоменклатуры" имеет периодичность "В пределах секунды", режим записи "Подчинение регистратору". Открыв документ "Установка цен номенклатуры". мы увидим, что дата документа ограничивается только днем месяца. В чем же дело. А дело в том, что "светлые головы" разработчиков 1с придумали к дате (поле "Период") каждой последующей записи в регистр сведений записываемой в один день по одной номенклатуре заданного вида цен, добавлять 1 секунду. В принципе это разумно, не будем же мы изменять цену каждую секунду суток. Поэтому хотя видно, что в документах за день стоит одна и таже дата, поле "Период" регистра сведений по номенклатуре будет содержать не нулевое количество секунд.

    Для получения последней цены за день из регистра сведений "ЦеныНоменклатуры", воспользуемся немного модифицированным запросом среза последних из раздела "Введение" публикации "Заметки по SQL: Срез последних - аналог запроса"

 
 Запрос получения последней цены за день в периоде отчета
ВЫБРАТЬ
	ЦеныНоменклатуры.ВидЦены КАК ВидЦены,
	ЦеныНоменклатуры.Номенклатура КАК Номенклатура,
	ЦеныНоменклатуры.Характеристика КАК Характеристика,
	НАЧАЛОПЕРИОДА(ЦеныНоменклатуры1.Период, ДЕНЬ) КАК Период,
	ЦеныНоменклатуры.Цена КАК Цена
ПОМЕСТИТЬ БазаЦен
ИЗ
	РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры1
		ПО ЦеныНоменклатуры.ВидЦены = ЦеныНоменклатуры1.ВидЦены
			И ЦеныНоменклатуры.Номенклатура = ЦеныНоменклатуры1.Номенклатура
			И ЦеныНоменклатуры.Характеристика = ЦеныНоменклатуры1.Характеристика
ГДЕ
	ЦеныНоменклатуры1.Период МЕЖДУ &ДатаНач И &ДатаКон

СГРУППИРОВАТЬ ПО
	ЦеныНоменклатуры.Номенклатура,
	ЦеныНоменклатуры.ВидЦены,
	ЦеныНоменклатуры.Характеристика,
	НАЧАЛОПЕРИОДА(ЦеныНоменклатуры1.Период, ДЕНЬ),
	ЦеныНоменклатуры.Цена,
	ЦеныНоменклатуры.Период

ИМЕЮЩИЕ
	МАКСИМУМ(ЦеныНоменклатуры1.Период) = ЦеныНоменклатуры.Период

 

    Следующим шагом нам необходимо получить выборку с данными последних цен с периодичностью "День" на начало и конец заданного в отчете периода. Для этого воспользуемся виртуальной таблицей "СрезПоследних" и нашим первым запросом "БазаЦен".

 
 Полная выборка цен номенклатуры за период.

    По поводу запроса можно сделать небольшой комментарий. В отборах к виртуальным таблицам использована следующая конструкция оператора отбора "В":

 
 Используемая конструкция оператора отбора "В"

    Почему использована раздельная конструкция оператора отбора "В", ведь можно проще и короче:

 
 Вариант короткой конструкции оператора отбора "В"

     Все просто, не смотря на то, что вторая конструкция выглядит проще и короче, она существенно проигрывает в быстродействии первой конструкции. И это понятно, в первой конструкции оператор "И" отбирает нужную номенклатуру без проверки на вид цены. Тогда как вторя конструкция сразу проверяет и номенклатуру и вид цены. К тому же количество записей для проверки второй конструкции будет значительно больше чем в первой.

    Построим запрос "Сумма накоплением" для нумерации цен в группе вид цены, номенклатура по периоду. 

 
 Запрос нумерации цен в группе вид цены, номенклатура по периоду

     Для вычисления изменения цены по сравнению с предыдущим периодом действия необходимо соединить эту временную таблицу с собой со сдвигом номера в группе на -1 (Первая.НомерВгруппе - 1 = Первая1.НомерВгруппе) и собственно рассчитать изменение цены в % по формуле  Первая.Цена * 100 / Первая1.Цена - 100.

     Для получения диапазон дат действия цены необходимо выполнить еще одно соединение, только со смещением +1 (Первая.НомерВгруппе + 1 = Первая2.НомерВгруппе), тогда диапазон дат действия цены будет - Первая.Период - Первая2.Период, и количество дней действия цены вычисляется как  - РАЗНОСТЬДАТ(Первая.Период, Первая2.Период, ДЕНЬ). Код выходного запроса полностью представлен ниже.

 
 Запрос вычисляющий изменение ресурса
ВЫБРАТЬ
	Первая.НомерВгруппе КАК НомерВгруппе,
	Первая.ВидЦены КАК ВидЦены,
	Первая.Номенклатура КАК Номенклатура,
	Первая.Характеристика КАК Характеристика,
	Первая.Цена КАК Цена,
	ВЫРАЗИТЬ(ВЫБОР
			КОГДА ЕСТЬNULL(Первая1.Цена, 0) = 0
				ТОГДА 0
			ИНАЧЕ Первая.Цена * 100 / Первая1.Цена - 100
		КОНЕЦ КАК ЧИСЛО(12, 2)) КАК Изменение,
	Первая.Период КАК Период,
	Первая2.Период КАК Период2,
	РАЗНОСТЬДАТ(Первая.Период, Первая2.Период, ДЕНЬ) КАК КоличествоДней
ИЗ
	Первая КАК Первая
		ЛЕВОЕ СОЕДИНЕНИЕ Первая КАК Первая1
		ПО Первая.ВидЦены = Первая1.ВидЦены
			И Первая.Номенклатура = Первая1.Номенклатура
			И Первая.Характеристика = Первая1.Характеристика
			И (Первая.НомерВгруппе - 1 = Первая1.НомерВгруппе)
		ЛЕВОЕ СОЕДИНЕНИЕ Первая КАК Первая2
		ПО Первая.ВидЦены = Первая2.ВидЦены
			И Первая.Номенклатура = Первая2.Номенклатура
			И Первая.Характеристика = Первая2.Характеристика
			И (Первая.НомерВгруппе + 1 = Первая2.НомерВгруппе)
ГДЕ
	НЕ Первая2.Период ЕСТЬ NULL

УПОРЯДОЧИТЬ ПО
	Первая.ВидЦены.Наименование,
	Номенклатура,
	Характеристика,
	Период

 

   Практическая реализация данного метода вычисления изменения ресурса осуществлена в публикациях "Продажи в динамике изменения цен номенклатуры за период" и "Реестр показаний по приборам учета за период с расчетом среднего потребления ресурса".

См. также

Инструментарий разработчика Роли и права Запросы СКД Программист Руководитель проекта Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Платные (руб)

Инструменты для разработчиков 1С 8.3: Infostart Toolkit. Автоматизация и ускорение разработки на управляемых формах. Легкость работы с 1С.

12000 руб.

02.09.2020    169256    937    403    

905

Запросы Программист Бесплатно (free)

Увидел cheatsheet по SQL и захотелось нарисовать подобное, но про запросы.

18.10.2024    11390    sergey279    18    

65

Запросы Программист Платформа 1С v8.3 Запросы Конфигурации 1cv8 Бесплатно (free)

Столкнулся с интересной ситуацией, которую хотел бы разобрать, ввиду её неочевидности. Речь пойдёт про использование функции запроса АВТОНОМЕРЗАПИСИ() и проблемы, которые могут возникнуть.

11.10.2024    6338    XilDen    36    

83

Запросы Программист Запросы Бесплатно (free)

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

16.08.2024    9066    user1840182    5    

28

Математика и алгоритмы Запросы Программист Платформа 1С v8.3 Запросы Бесплатно (free)

Рассмотрим быстрый алгоритм поиска дублей с использованием hash функции по набору полей шапки и табличных частей.

08.07.2024    2727    ivanov660    9    

22

Запросы СКД Программист Стажер Система компоновки данных Россия Бесплатно (free)

Часто при разработке отчетов в СКД возникает ситуация, когда не совсем понятно, почему отчет выводит не те данные, которые нужны, либо не выводит вовсе. Возникает потребность увидеть конечный запрос, который формирует СКД. Как это сделать, рассмотрим в этой статье.

15.05.2024    10218    implecs_team    6    

48

Запросы Программист Стажер Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Часто поступают задачи по произвольному распределению общих сумм. После распределения иногда пропадают копейки. Суть решения добавить АвтоНомерЗаписи() в ВТ распределения, и далее используя функции МАКСИМУМ или МИНИМУМ можем положить разницу копеек в первую или последнюю строку знаменателя распределения.

11.04.2024    3623    andrey_sag    10    

38
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. bulpi 217 11.04.19 17:45 Сейчас в теме
РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныНоменклатуры1


Автор, ну елы-палы. Это у Вас работает в тестовой базе. В реальной базе за несколько лет работы этот запрос уснет навсегда. Дальше читать не стал.
3. IVC_goal 227 11.04.19 17:57 Сейчас в теме
(1) Ну да если поставить ЦеныНоменклатуры1.Период МЕЖДУ &ДатаНач И &ДатаКон в несколько лет, а ведь можно и больше. Приведите пример из реальной базы, если она у вас есть. Посмотрите ссылкуMy Webpage, там есть и другие отборы. А по всей номенклатуре и всем видам цен, я с Вами и спорить не буду, только как Вы будете это анализировать?
5. bulpi 217 12.04.19 10:40 Сейчас в теме
(3)
Похоже, Вы думаете, что поможет вот это :
ГДЕ
ЦеныНоменклатуры1.Период МЕЖДУ &ДатаНач И &ДатаКон


Нет, не поможет. Убеждать не буду, каждый должен сам через это пройти.
2. bulpi 217 11.04.19 17:49 Сейчас в теме
Так это сюда еще ildsrovich не зашел. А то ведь полетят клочки по закоулочкам :)
4. IVC_goal 227 11.04.19 17:58 Сейчас в теме
6. Bеgemoth 18.04.19 13:20 Сейчас в теме
(0) "... не смотря на то, что вторая конструкция выглядит проще и короче, она существенно проигрывает в быстродействии первой конструкции. И это понятно, в первой конструкции оператор "И" отбирает нужную номенклатуру без проверки на вид цены. Тогда как вторя конструкция сразу проверяет и номенклатуру и вид цены. К тому же количество записей для проверки второй конструкции будет значительно больше чем в первой."

Это далеко не так, время выполнения определяется многими условиями. Но это ладно, скорость - предмет темный и исследованию не подлежит. А не смущает, что это два разных условия отбора, которые будут давать разный результат?
7. IVC_goal 227 18.04.19 14:21 Сейчас в теме
(6)Правильный результат будет давать первый отбор с условием "И ", что касается второй конструкции, то это изобретение 1с, по вашему замечанию я неправильно понимаю,. Поэтому если Вас не затруднит поясните различие и я исправлю текст статьи
8. Bеgemoth 18.04.19 14:37 Сейчас в теме
(7) "Правильность" или "неправильность" результата целиком зависит от того, какую цель вы ставите перед этим отбором, поэтому судить об этом не могу.
А разница в следующем:
если у вас исходная таблица вида:
((Номенклатура1, ВидЦены1), (Номенклатура1, ВидЦены2), (Номенклатура2, ВидЦены1), (Номенклатура2, ВидЦены2))
и таблица отбора вида:
((Номенклатура1, ВидЦены1), (Номенклатура2, ВидЦены2))
тогда
первое условие "Номенклатура В () И ВидЦены В ()" даст результат:
((Номенклатура1, ВидЦены1), (Номенклатура1, ВидЦены2), (Номенклатура2, ВидЦены1), (Номенклатура2, ВидЦены2))
второе условие "(Номенклатура, ВидЦены) В ()" даст результат:
((Номенклатура1, ВидЦены1), (Номенклатура2, ВидЦены2))
9. IVC_goal 227 18.04.19 15:26 Сейчас в теме
(8) Спасибо за ответ. Если есть Номенклатура1 и у нее нет ВидЦены2 и есть Номенклатура2 и у нее нет ВидЦены1, то первый отбор будет эквивалентно второму поскольку номенклатуры с отсутствующими видами цен не отберутся. И наоборот, если у Номенклатура1 есть ВидЦены2 и у Номенклатура2 есть ВидЦены1, то отборы опять эквивалентны, поскольку и по второму отбору это условие тоже выполнится. То есть, если выбираются всевозможные варианты комбинации Номенклатура - вид цены, то отборы эквивалентны. В чем я не прав?
10. Bеgemoth 18.04.19 15:46 Сейчас в теме
(9) Если вы имеете в виду, что и в таблицу БазаЦен и в таблицу ВыборкаЦен данные берутся из одного источника, то могу указать на условие в таблице БазаЦен:
ГДЕ
... ЦеныНоменклатуры1.Цена <> 0

При условии с "И" есть вероятность, что в таблицу ВыборкаЦен попадет строка с нулевой ценой. При условии "(Номенклатура, ВидЦен) В " нулевая строка в таблицу ВыборкаЦен не попадет.
Именно это я и имел в виду, когда писал, что это разные условия отбора, которые дадут разный результат.

Для примера проверьте на наборе данных (Номенклатура, ВидЦен, Цена):
Номенклатура1, ВидЦены1, 100
Номенклатура1, ВидЦены2, 100
Номенклатура2, ВидЦены1, 100
Номенклатура1, ВидЦены2, 0

Если же строка с нулевой ценой в таблице ВыборкаЦен роли не играет, тогда зачем ставить условие в таблице БазаЦен?
11. IVC_goal 227 18.04.19 16:26 Сейчас в теме
(10) Согласен с Вашим замечанием. Строго говоря нулевая цена это ошибка ввода данных, и условие в таблице ВыборкаЦен лишнее, такая ситуация должна обрабатываться. Спасибо за конструктивную дискуссию и потраченное время. Если Вас заинтересовали мои обработки пишите в личку вышлю любую на выбор.
Оставьте свое сообщение