Версия ЛЭРС УЧЁТ: 3.58.3
Сервер БД: PostgreSQL
Сводный по параметрам ИТП c 18.09.2024 по 18.09.2024.pdf (56,4 КБ)
Сводный по параметрам ИТП.lersreport (13,2 КБ)
Спасибо за обращение! Мы поставили в план работ исправление данной ошибки. Как только она будет исправлена, обязательно сообщим в каком обновлении будет доступно исправление.
Исправление будет доступно в следующей версии 3.58.4.
Добрый день!
Обновление 3.58.4 (сборка 35812) от 26.09.2024 доступно для установки.
не исправлено
Покажите, пожалуйста, сформированный в текущей версии отчет по ранее присланной отчетной форме.
Уточните за какой период формировали данные? Покажите таблицу с данными, по которым формировался отчет, за период его формирования по первым 2-м точкам из присланного отчета.
Также уточните, вы импортируете данные в справочник Среднесуточных температур с помощью утилиты ImportTemperature? Если да, уточните какой сервис используется в качестве источника?
c 24.09.24 по 24.09.24 суточные
Таблица данных Лёт. Лихолетова 14 к2 с1 - ИТП 3 Регулятор.xlsx (5,6 КБ)
Таблица данных Лёт. Лихолетова 14 к2 с1 - ИТП 4 Регулятор.xlsx (5,7 КБ)
импортирую этой штукой Утилита импорта среднесуточных температур с сайта open-meteo.com
Тогда уточните этот момент:
Мы проанализировали эту ситуацию и оказалось, что сейчас есть возможность некорректного взаимодействовать со справочником среднесуточных температур через API. Справочник предполагает наличие одной записи для дня с 00 часов, однако через API можно установить не 00 метку времени и сохранить несколько записей для одного дня. Из-за это некоторые проверки могут определять дату некорректно и данные не отображаются.
Мы поставили в план задачу по исправлению данного поведения, чтобы через API записывались корректные метки времени. И так же исправим существующие записи в справочнике. Исправление войдёт в обновление 3.59.
Так же сейчас можете попробовать в своём скрипте изменить формируемую метку времени на 00 часов, удалить существующие данные из справчоника и произвести повторный импорт.
не помогло
Попробуйте выполнить данный шаг еще раз, но после штатного удаления также в самой БД в таблице справочника среднесуточных температур “OutdoorTemperature” удалить все записи с меткой времени не “00:00”. В этом случае после повторного импорта должны остаться только записи на “00:00” и ситуация возникнуть не должна.
в таблице нет записей с меткой времени отличной от “00:00”, зато заметил иное.
Я импортировал даты с указанием ‘timezone’, как это указано в swagger. В итоге метки времени в таблице выглядят так: ‘2024-01-30 00:00:00.3’, хотя описание колонки в таблице гласит [PK] timestamp without time zone.
Мне убрать из скрипта указание ‘timezone’?
Эта ситуация не может быть связана с таймзоной. У вас в метке времени присутствуют миллисекунды и проблема судя по всему именно в этом. То есть система ищет записи с меткой времени ровно на “00:00:00”, а наличие миллисекунд в записи “00:00:00.3” делает ее отличной от “00:00:00”.
Попробуйте удалить такие записи и заново провести импорт при помощи утилиты ImportTemperature. Проверьте какими будут метки времени после этого.
Добрый день!
Обновление 3.59.0 (сборка 35904) от 22.10.2024 доступно для установки.
Добрый день!
Обновление 3.59.0 (сборка 35904) от 24.10.2024 доступно для установки.