Неточности при расчете среднесуточных значений

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

Для того, чтобы разобраться сделал отчет, где по каждому параметру подсчитывается среднее за период с помощью средств отчета в строке “Итого” и в отдельнуй колонке, справа от каждого параметра, выводится среднее, которое считает ЛЭРС Учет.
Пример, когда в отчетом периоде есть все данные, на мой взгляд, все корректно.
16-12-2019 17-22-12.png
А вот скрин, когда отчет за период, где есть не все данные. И каждый параметр посчитан не верно.
16-12-2019 17-23-36.png
Присылать Вам данные и шаблон не вижу смысла, вроде все достаточно прозрачно.

Шаблон отчетной формы очень бы пригодился и ускорил решение вашего вопроса.

Судя по всему в настройках сводки в свойствах каждой ячейки таблицы, в которой выводятся средние значения температур, у вас выставлен параметр “Игнорировать нулевые значение” (в редакторе сводки он же именуется как “Пропускать значения NULL”).
Специально для вас я подготовил анимационный файл, в котором отражено расположение данного параметра.
Расположение парамтера сводки ячейки таблицы Игнорировать нулевые значения.gif

Иван, вопрос не про мое умение/не умение строить шаблон отчета, а про то, что ЛЭРС Учет неправильно рассчитывает среднесуточные значения. И это я показал с помощью специально сделанного отчета.

ЛЭРС УЧЕТ рассчитывает итоговые данные в отчете согласно тому, как вы спроектировали отчетную форму и вопрос как раз в этом. Я написал вам возможный параметр отчетной формы, который может влиять на расчет.

Повторюсь, судя по всему в настройках сводки в свойствах каждой ячейки таблицы, в которой выводятся средние значения температур, у вас выставлен параметр “Игнорировать нулевые значение” (в редакторе сводки он же именуется как “Пропускать значения NULL”). Если вы хотите, чтобы нулевые значения учитывались при расчете средних, снимите вышеописанный флаг в каждой ячейке итогов. В противном случае в расчете будут участвовать только те записи, в которых присутствуют какие либо значения.

Вот тот же отчет, но я его раскрасил. Поля выделенные красным посчитаны в отчете, и они посчитаны только за период имеющихся данных, с установленный опцией “Пропускать значения NULL” (с 09/12 - 16/12)
17-12-2019 18-49-48.png
Поля же выделенные синим рассчитывает ЛЭРС Учет, не средствами отчета. Они доступны для использования в отчете в ветке:
Архивы потреблений и интеграторов - Рассчитанные значения - Среднесуточные значения.
17-12-2019 18-58-48.png
И на выделенные синим значения не оказывает никакого влияния настройка параметра “Игнорировать нулевые значение” (в редакторе сводки он же именуется как “Пропускать значения NULL”)"

Так вот. Ошибка, на мой взгляд, в значениях выделенных синим, т.к. программа считает из за период с 9/12 по 25/12, почему-то считая записи без данных за записи со значением нуль.

Прикладываю шаблон отчета и данные, если Вы видите в них какой-то смысл в этом случае.
Data_2019-12-17_1904.rar (413 KB)
test.lersreport (71.4 KB)

Если я правильно вас понимаю, ваш вопрос заключается в том, почему возникает разница между среднесуточными значениями, посчитанными в итоговых данных колонок измеряемых параметров, и среднесуточными значениями из одноименного раздела отчета, выводимых в колонках с приставкой “ср”.
Здесь нет никакой ошибки. При расчете среднесуточных значений из одноименного раздела отчета “Среднесуточные данные” учитываются все данные за весь период формирования отчета, исключая записи с нулевыми значениями. Мы импортировали присланные вами данные и обнаружили, что на дату формирования отчета из скриншота 17.12.2019 у вас есть неполные рассчитанные суточные данные и эти данные попадают в расчет среднесуточных значений из одноименного раздела отчет (период формирования отчета включает текущую дату) и получившиеся значения выводятся в колонке с приставкой “ср”, тогда как при расчете средних значений в итоговых данных по колонке измеряемых параметров (T1, G1, T2, G2) эти данные не попадают, так как в отчет выводятся данные только за прошедшие сутки.

Если вас не устраивает результаты расчета среднесуточных данных из одноименного раздела отчета “Среднесуточные данные”, вы можете создать вычисляемое поле и в нем настроить расчет среднесуточных значений только по данным выводимым в отчете, как и при подсчете итоговых данных в колонках измеряемых параметров.

Сейчас мы поняли друг друга. Отлично.

А вот это не так. Тут есть ошибка. И Вы подробно описали ее причину, но почему-то назвали особенностью программы :hi_hi_hi:
“Среднесуточные значения” у Вас в программе появились не просто так, а как упрощение при создании шаблонов, в том числе для заполнении периодов времени за которые еще нет данных. Причем, как замена вычисляемым полям, которые Вы предлагаете создать. :-):
Т.е. “Среднесуточные значения” нужны в конкретном отчете за отчетный период для отображаемых в отчете значений. И ни как иначе.
И если алгоритм расчета этих “среднесуточных значений” “цепляет” что-то еще, не отображаемое в отчете, то я считаю что это “косяк”

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

Расчет суммарных и среднесуточных значений за отчетный период не зависит от типа данных и использует все имеющиеся данные отчетного периода. Эти данные используются для расчета отсутствующих значений в конце отчетного периода, поэтому изменять их алгоритм расчета нельзя.

Суточные данные за текущий день всегда не полные и в текущей версии ЛЭРС УЧЕТ в суточный отчет не включаются, поэтому значения из узла рассчитанных могут не совпадать со значениями из строки Итого.

Т.к. отчет по суточным данным, подаваемый в энергоснабжающую организацию, формируются после окончания отчетного периода, то у пользователей такая проблема не возникала.
Если включить в отчет суточные данные за текущие сутки, то для тех кому они не нужны, а таких большинство, потребуется в отчетной форме использовать фильтрацию данных.
По моему гораздо проще при необходимости использовать вычисляемое поле с агрегатными функциями Avg() или Sum(), которые возвращают те же значения, что и в строке Итого.

Странно, что Вас не смущает написанное выше. Меня смущает. В отчет помещаем одни данные, а средние значения для этого отчета считаем не совсем по этим данным. Т.е. если в отчете будет недостающий период, то “итого” будет в любое время суток одинаково, а “среднесуточные значения” будут разные в отчете формируемом в 1 ночи, в 15 дня и в 23 вечера.
Вот не вижу, где мы молодцы :hi_hi_hi:
Вы считаете это нормальным? :hi_hi_hi:

На мой взгляд " значения из узла рассчитанных" обязаны “совпадать со значениями из строки Итого”

Это утверждение, если говорить про всю Россию, не верно

Она возникала, но расхождения были не большие и на них закрывали глаза. Но перед НГ кое-где сдают с большим интервалом и видимо более пристально проверяют. Мне нуже в двух местах указали на ЭТО

Ни в коем случае :ni_zia:

У нас разное понимание “проще”, но если использовать вычисляемые поля для обработки ситуаций: с наличием периода с отсутствующими данными или с неполной наработкой, то зачем вообще “узел среднесуточные значения”.

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

Во вторых. Я был инициатором появления этих усредненных значений, они появились для упрощения написания шаблонов в случаях описанных выше и с тех пор их использую активно. Не хотелось бы отказываться.

В третьих. Следуя Вашей логике, сейчас при проектировании отчетов нужно еще знать, а будут ли их использовать с пустыми интервалами. И в зависимости от этого использовать разные подходы :hi_hi_hi:

Резюме. Это важно. Отчет - это документ, который существует отдельно от ПО, после того как его сделали не важно, что осталось в ПО и при каких условиях его делали. Если его колонки при проверке не соответствуют друг другу, то отчет “кривой”

Кроме того, все что Вы написали выше не является единственной причиной расхождения среднесуточных, посчитанных ЛЭРСом (узел среднесуточные), и посчитанных в отчете (Итого). Ниже 2 отчета построенных по одним и тем же данным, но с разным количеством пустых записей. И значения среднесуточных, посчитанных ЛЭРСом, отличаются даже друг от друга - нужное выделено синим.


Резюмируя.
Правильно ли я понял, что достаточно включить в отчет по суточным данным данные за текущие сутки, а правила расчета средних в строке Итого определяет пользователь?

Нужно:

  • убрать из расчета значений в узле “среднесуточные …” текущие сутки;
  • и что то еще, т.к. в конце своего предыдущего поста в привел картинки показывающие, что дело не только в значениях текущего дня.

На скриншотах данные по тепловой энергии в строке Итого для колонок Qот и Qгвс различаются из-за снятого признака “Пропускать значения NULL” (так было в приложенной отчетной форме).

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

Не понял. Еще раз другими словами. Значения “Итого” формируются с отмеченной опцией “Пропускать значения NULL”, это видно по тому, что они не меняются вне зависимости от количества пустых строк. Такого же я ожидаю от значений в узле “среднесуточные”. Т.е.:

  • они должны быть равные значениям “итого”;
  • не меняться при изменении количество пустых строк (записей без данных).

Нужно, что-то пояснять?

Я отвечал в контексте задачи. Сейчас ЛЭРС Учет не помещает текущую запись суточного архива в отчеты всех видов; как поступает с месячными и часовыми не знаю, эти архивы пока меня не интересуют. Я предлагаю не использовать текущую запись суточного архива и при расчете значений в узле “среднесуточные” .
Т.е. мои слова никак не касались ограничений отчетов с часовыми значениями

Хорошо.
Если это не критично, то корректировку расчета среднесуточных значений мы сделаем в ЛЭРС УЧЕТ версии 3.34

Отлично. В 3.34 тоже - нормально. Буду ждать

да, все верно

Это изменение вошло в 3.34?

Да, это изменение вошло в версию 3.34.