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
Автор, ну елы-палы. Это у Вас работает в тестовой базе. В реальной базе за несколько лет работы этот запрос уснет навсегда. Дальше читать не стал.
Так это сюда ещеildsrovich не зашел. А то ведь полетят клочки по закоулочкам 🙂
(1) Ну да если поставить ЦеныНоменклатуры1.Период МЕЖДУ &ДатаНач И &ДатаКон в несколько лет, а ведь можно и больше. Приведите пример из реальной базы, если она у вас есть. Посмотрите ссылкуMy Webpage , там есть и другие отборы. А по всей номенклатуре и всем видам цен, я с Вами и спорить не буду, только как Вы будете это анализировать?
(2) Жду с нетерпением
(3)
Похоже, Вы думаете, что поможет вот это :
ЦеныНоменклатуры1.Период МЕЖДУ &ДатаНач И &ДатаКон
Нет, не поможет. Убеждать не буду, каждый должен сам через это пройти.
(0) «… не смотря на то, что вторая конструкция выглядит проще и короче, она существенно проигрывает в быстродействии первой конструкции. И это понятно, в первой конструкции оператор «И» отбирает нужную номенклатуру без проверки на вид цены. Тогда как вторя конструкция сразу проверяет и номенклатуру и вид цены. К тому же количество записей для проверки второй конструкции будет значительно больше чем в первой.»
Это далеко не так, время выполнения определяется многими условиями. Но это ладно, скорость — предмет темный и исследованию не подлежит. А не смущает, что это два разных условия отбора, которые будут давать разный результат?
(6)Правильный результат будет давать первый отбор с условием «И «, что касается второй конструкции, то это изобретение 1с, по вашему замечанию я неправильно понимаю,. Поэтому если Вас не затруднит поясните различие и я исправлю текст статьи
(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))
(8) Спасибо за ответ. Если есть Номенклатура1 и у нее нет ВидЦены2 и есть Номенклатура2 и у нее нет ВидЦены1, то первый отбор будет эквивалентно второму поскольку номенклатуры с отсутствующими видами цен не отберутся. И наоборот, если у Номенклатура1 есть ВидЦены2 и у Номенклатура2 есть ВидЦены1, то отборы опять эквивалентны, поскольку и по второму отбору это условие тоже выполнится. То есть, если выбираются всевозможные варианты комбинации Номенклатура — вид цены, то отборы эквивалентны. В чем я не прав?
(9) Если вы имеете в виду, что и в таблицу БазаЦен и в таблицу ВыборкаЦен данные берутся из одного источника, то могу указать на условие в таблице БазаЦен:
ГДЕ
… ЦеныНоменклатуры1.Цена <> 0
При условии с «И» есть вероятность, что в таблицу ВыборкаЦен попадет строка с нулевой ценой. При условии «(Номенклатура, ВидЦен) В » нулевая строка в таблицу ВыборкаЦен не попадет.
Именно это я и имел в виду, когда писал, что это разные условия отбора, которые дадут разный результат.
Для примера проверьте на наборе данных (Номенклатура, ВидЦен, Цена):
Номенклатура1, ВидЦены1, 100
Номенклатура1, ВидЦены2, 100
Номенклатура2, ВидЦены1, 100
Номенклатура1, ВидЦены2, 0
Если же строка с нулевой ценой в таблице ВыборкаЦен роли не играет, тогда зачем ставить условие в таблице БазаЦен?
(10) Согласен с Вашим замечанием. Строго говоря нулевая цена это ошибка ввода данных, и условие в таблице ВыборкаЦен лишнее, такая ситуация должна обрабатываться. Спасибо за конструктивную дискуссию и потраченное время. Если Вас заинтересовали мои обработки пишите в личку вышлю любую на выбор.