Версия ЛЭРС УЧЁТ: 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’?