После закрытия темы " Драйвер СПГ741 сдвигает дату у суточных вперед",
я обнаружил, что слишком поторопился сообщить, что мне помогло предложенное Иваном Славным решение - установка галочки “группировка часовых “По умолчанию”.
Иван Славный приложил к сообщению картинку, где видно, что суточные совпадают с суммой часовых.
Вот это картинка:
А вот картинка, на которой в заводской программе я выделил те же часовые данные (совпадают все значения), которые видны на предыдущей картинке за сутки 20.05.2024.
Обратите внимание, в СПГ741 расчетный час = 13.
У Ивана Славного на картинке, развернуты сутки 20.05.2024, часовые в этих сутках должны считаться, начиная с 13:00 20.05.2024, по 13:00 21.05.2024
На картинке с заводской программой видно, что именно эти же значения начинаются с 14:00 19.05.2024 по 14:00 20.05.2024.
Вот ещё одна картинка из заводской программы Пролог, на которой выделены часовые с 14:00 20.05.2024 по 14:00 21.05.2024, то есть те самые, которые должны были быть видны на картинке Ивана Славного за 20.05.2024
Программисты ЛЭРС не учли, что у разработчиков СПТ принято называть архивы по концу отчётного периода. Например, часовые на 13 часов у них - это показания за промежуток времени с 12-00 до 13-00, не как в ЛЭРС УЧЁТ.
Прочитал статью, не помогло.
В ЛЭРС УЧЁТ для СПГ 741 время хранится точно такое, какое в программе Пролог, и в этом заключается ваша ошибка. А должна быть разница, причина которой описывается в предложенной вами статье.
Причина данных расхождений описана в приведенной мною статье. Разные способы хранения данных в ЛЭРС УЧЕТ и в ПРОЛОГ не является ошибкой. Вы можете разработать собственную отчетную форму, в которой вдвинуть метку времени (суточных или часовых), чтобы она выглядела как в программе ПРОЛОГ, о чем собственно и говорится в статье.
Нет, это данные за 19е число, они сохранены в базе именно на 19 мая. На 20е они попали из-за того, что отчётный час установлен в 13. В этом случае мы группируем записи с 19 мая 13:00 до 20 мая 13:00 на 20е мая, так как большая часть часовых записей находится именно в 20м числе.
Для проверки установите отчётный час и день в этой точке в 1 и снова откройте таблицу с данными. Суммы совпадать перестанут, зато вы увидите то, как данные хранятся в БД.
Отмечу, что вы можете сделать группировку на начала дня. Для этого в точке учёта есть настройка “Отчётный час указывает на начало дня”. Только тогда у вас перестанут совпадать сумма часовых и суточные данные.
Непонятно, откуда взялось такое правило, совершенно бестолковое. Предлагаю его ликвидировать и всегда группировать с начала отчетного периода, так и сделано в Прологе. Не будет этой путаницы и сумма часовых будет совпадать с суточными.
Значит мне здесь никто не поможет. У меня забавная ситуация:
В котельной есть общекотельный узел учёта газа СПГ761.2, он считает сумму газа, потребляемого котлами и генератором электроэнергии. Генератор вырабатывает электроэнергию для насосов в колельной. Он работает на газовом топливе, и для него установлен узел учёта газа СПГ741. Сейчас отопительный сезон закончен, и котлы перестали потреблять газ. Теперь весь газ, проходящий через СПГ761.2, идет через СПГ741 на генератор, и показания обоих узлов учета газа должны совпадать.
Но, в СПГ761.2 расчетный час = 12, а в СПГ741 расчетный час = 13. В результате, куда эту галочку ни ставь, появляется несовпадение показаний на целые сутки, то суточных, то часовых.
Теперь понятно, что нужно будет делать в обоих СПГ одинаковый расчётный час. Спасибо за объяснения.
Жаль, что вы в таблицах потребления решили группировать данные по правилам Пролога. У вас есть свои правила, которые и нужно было соблюдать. Простые и понятные: группировка по началу периода. Везде.
А те пользователи, которые хотят видеть таблицы, как в Прологе, как раз и должны сами делать для этого отчетную форму. Проблем бы намного меньше было.
