Пользовательский атрибут является строкой. Вам нужно преобразовать его в число функцией ToDouble.
Используйте пример из статьи Использование параметров отчета.
Давайте разбираться.
Атрибут равен 9,4, Формулу показал.
Для проверки использую значение часового архива за 23/04/25. Значения 10,4 в прочих часах результат прочих эксперементов. Значение на 13:00 я изменил вручную на “0”.
Проверяли точно вашу формулу, но всё работает как ожидалось - подставляется значение из атрибута.
Насколько я прочитал ваш скриншот, вы показали его до того как нажали кнопку “Пересчитать”. Иначе введённое значение 0 за 13:00 тоже было бы заменено на расчётное. Может, у вас просто возникает какая-то ошибка обращения к БД? Что-то есть в системном журнале?
Не заменилась как раз потому, то не подставился атрибут
Когда не заработало заполнение пользовательским атрибутом, я проверил работу с константами - данные заполнились. После этого для дальнейшего контроля ввел “0” за 13:00 и еще раз проверил с атрибутами. Ноль не переписался на значение атрибута
Никаких ошибок в логах нет. Формулы без атрибутов с участием констант и измеряемых параметров работают
В любом случае, мы не может воспроизвести ситуацию на 3.61. Все атрибуты корректно подставляются при расчёте. Пожалуйста, попробуйте на актуальной версии.
не знаю что значит этот термин в этом случае, но вот сообщение из системного журнала об этом: “Ошибка расчёта формул для точки учёта 4-й микрорайон, 31 - Теплоснабжение. Ошибка вычисления параметра за 05.05.2025 13:47 по выражению ‘(ToDouble([124.Parent_Attribute.Set-pointflow]) - [&Heat1.5]) / ToDouble([124.Parent_Attribute.Set-pointflow]) * 100’. Имя поля &Heat1.5 задано неверно. Имя поля &Heat1.5 задано неверно. The input string ‘&Heat1’ was not in a correct format. Имя поля &Heat1.5 задано неверно. Имя поля &Heat1.5 задано неверно. The input string ‘&Heat1’ was not in a correct format.”
У термина “выдержка” действительно существует несколько определений, но в контексте работы с текстовой информацией, к которой относится и журналы, мне удалось найти только единственное определение из толкового словаря Ушакова (см. пункт 1. здесь).
Из приложенного вами текста ошибки видно, что ошибка возникает вовсе не с атрибутом “Set-pointflow”, о котором вы писали ранее. Ошибка возникает в выражении, в котором задействовано и упомянутый атрибут “Set-pointflow”, и некий атрибут “Heat1.5”, с которым как раз и возникает ошибка. Обратите внимание, что среди приложенных вами ранее скриншотов выражений нет выражения с упомянутым в ошибке текстом, а значит приложенная вами информация в том комментарии была неполной.
Суть данной ошибки в том, что у вас в коде атрибута “Heat1.5” присутствует символ точки “.”, что собственно и является ошибкой, так как в выражениях данный символ является разделителем. Выдвинутое вами ранее предположение:
не подтвердилось.
Пожалуйста, удалите из кода “Heat1.5” символ точки “.” и измените все выражения, в которых данный код был задействован, изменив старый код с точкой на новый без точки.
Я не знаю, что вам ответить.
Я показал, что ЛЭРС предлагает использовать пользовательский атрибут объекта и как атрибут всех точек этого объекта. Это явно ошибка. Хотя вам виднее
Первоначально в выражении использовался атрибут объекта как атрибут точки.
Я это исправил, и проблема исчезла.
Heat1.5 - это явна подмена названия точки учета ЛЭРСом, на какое-то внутреннее имя. Как это выглядит при вводе видно на скриншоте. Логика внутрипрограммного нейминга мне непонятна и не важна сейчас. Наличие и отсутствие точки в синтаксисе определял не я, это подстановка в редакторе выражений.
Резюме, я разобрался с причиной неработающего расчета.
Если вы считаете, что всё в порядке - закройте тему. Если согласны со мной и видите ошибку - тоже понятен порядок действий.
У нас данная ситуация не воспроизводится. Атрибут объекта, задействованный в формуле точки, не вызывает каких либо ошибок и его значение корректно используется при расчете по данной формуле.
Heat1.5 это не внутреннее имя. Такое имя судя по всему задано одному из атрибутов. Проверьте пожалуйста в справочнике атрибутов атрибут с таким именем.
Оказалось, я не убрал вчера расчет h, но добавил в формулу массу по циркуляции ГВС, и формула работала, вызывая ошибку. Текст сообщения об ошибке в системном журнале выглядит так:
Ошибка расчёта формул для точки учёта 4-й микрорайон, 31 - Теплоснабжение. Ошибка вычисления параметра за 06.05.2025 11:34 по выражению ‘(ToDouble([124.Parent_Attribute.Set-pointflow]) + [&HotWater1.6] - [&Heat1.5]) / ToDouble([124.Parent_Attribute.Set-pointflow]) * 100’. Имя поля &HotWater1.6 задано неверно. Имя поля &HotWater1.6 задано неверно. The input string ‘&HotWater1’ was not in a correct format. Имя поля &HotWater1.6 задано неверно. Имя поля &HotWater1.6 задано неверно. The input […]
Скриншот формулы не приведу, удалил её раньше вашего сообщения, но в тексте сообщения об ошибке она видна.
Очень похоже, что вы заблуждаетесь.
Heat1.5 - это М1 в точке Теплоснабжения с 1-ым порядковым номером в объекте.
HotWater1.6 - М2 в точке ГВС с 1-ым порядковым номером в объекте.
Не вижу тот проблемы, о которой вы написали. Да, атрибут создан для объекта. Если я правильно понял, объект учёта называется 4-й микрорайон, 31 и у него есть точка учёта Теплоснабжение.
Соответственно, один и тот же атрибут можно вызвать разными способами.
Или напрямую из объекта. Это на вашем первом скриншоте параметр 4-й микрорайон, 31: Расход настроечный
Или же из ссылочной точки учёта через её объект. В этом случае параметр называется ССЫЛКА НА ТОЧКУ - Объект учёта: Расход настроечный. На остальных ваших скриншотах как раз тот же самый атрибут родительского объекта для ссылочных точек учёта. Так удобнее работать со ссылками. Например, берёте &Эта точка и обращаетесь к атрибуту Расход настроечный её родительского объекта.
Ошибка у вас где-то в другом месте, скорее всего, в синтаксисе формулы. Об этом говорит сообщение в системном журнале. Но на актуальной версии именно эта формула работает и возвращает нужное значение.
