[14743] Добавить возможность исключить информацию о просроченной поверки из расчета состояния объектов

Не нашел как:

  • отключить НС из-за просроченной поверки
  • исключить НС из-за просроченной поверки из расчета состояния объектов для конкретной учетной записи
1 лайк

У нас нет нештатных ситуаций о просроченной поверке. Поясните подробнее что вы имеете в виду.

Мне нужно управлять статусом объекта. Если поверку не ведут в ЛЭРСе, а только заведены приборы, то получается такая картина
image

Мне нужно исключить эту информацию о просроченной поверки из расчета состояния объектов для конкретной учетной записи.

Если поверку не ведут, почему не очистить параметр “Дата следующей поверки”? Тогда она не учитывается в состоянии для расчёта.

Кстати, очистить можно групповой операцией со списка объектов. Выбрать флажками нужные объекты, нажать кнопку “Редактировать” и оставить пустым поле “Дата следующей поверки”.

А зачем уничтожать информацию? Она была заполнена, но не актуализирована пока. Эта информация осознано хранится в ЛЭРСе

Мешает статус объекта. В текущем положении не получается пользоваться диагностикой, т.к. статус у объектов, где НС и где просрочена поверка одинаковый.

Предложение поддерживаю. Возможность настроить влияние на расчет статуса объекта для определенной учетной записи нас тоже интересует.
Необходимость ровно такая же, как описал @Kvashnin

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

Я прошу сделать возможность исключить состояние поверки из расчета состояния объектов для пользователей.

Вы же предлагаете мне сделать выбор:

  • хранить только актуальную информацию о поверке
  • удалить данные о поверке всех устройств и отказаться от использования ЛЭРСа в качестве хранения данных о поверке

Для меня это разные вопросы. Не понимаю, почему Вы их объединяете.

Данные о поверке не актуализируются по разным организационным причинам. Вы сейчас сформировали новое требование к использованию Вашего ПО.

Сейчас как только поверка заканчивается - состояние статуса меняет свой смысл. Он уже не отражает привычную для пользователя информацию, а делает его красным. Хотя до этого красный цвет говорил о наличии вполне определенных НС, связанных с режимами и объемом потребления и работой оборудования.

При этом статус, с настроенными вручную НС, используется и на мнемосхемах с картами и просто картах. При окончании поверки в точке, используемой на мнемосхеме, смысл мнемосхемы меняется. А мнемосхемы обычно не должны содержать информацию поверке

Т.е. ваш подход ломает использование статуса на мнемосхемах и картах.

Кроме того, мне не понятно, почему я могу настроить какие НС отображать в статусе для конкретного пользователя, но не могу отключить использование данных о поверке.
Т.е. Вы допускаете, что не всем пользователям нужны все виды НС, но настаиваете, чтобы все пользователи видели информацию о поверке.

Хм…

1 лайк

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

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

Нет не меняется, с чего бы?

Проблема в том, что вы считаете статус статусом НС, но на самом деле это не так.

не вижу этого

:slight_smile: Вы назвали, то что обсуждали другими словами и решили, что это аргумент :slight_smile:

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

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

Как ведется учет поверки и допуска, на мой взгляд, не должно влиять на маркировку объектов, если пользователю не нужно знать про эти вопросы. Возможно вы не учитываете, что показания с узлов учета используются для технологических целей, в этом случае пользователи не хотят видеть “лишние” для них данные.

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

Как я написал выше, вы сделали состояние гибким в отношении НС, но почему-то негибким в отношении допуска и поверки. И я тут вижу противоречия.

У вас 2 неточности в статье, на которую ссылаетесь:

  • по док-ции поверка не используется для расчета состояния

  • для предупреждения зачем-то придуман термин “некритические нештатные ситуации”, который вроде больше не используется и приходится искать, о чем идет речь

Пока я всё ещё не вижу проблемы в том, чтобы убрать дату поверки в случае если они не используются. Тем более, что эти параметры в таком случае показывают некорректные данные.

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

Не понял, о каких параметрах речь. Предположу, что о дате поверки.

Вы связали 3 параллельные, не пересекающиеся вещи в одной и они мешают друг другу. Обслуживание поверки в ЛЭРС Учете - трудоемкое дело, до интеграций с Аршином, вообще в большинстве случаев сомнительное из-за высоких трудозатрат на поддержание.

После интеграции с Аршином привлекательность сильно выросла, но нужно проверять результат интеграции периодически. Т.е. этот процесс породил новую операцию, требующую время.

В процессе обсуждения оказалось что, если дата поверки сама не «встала», то нужно оперативно с ней разобраться. Сотрудники отвечающие за поверку должны постоянно контролировать, что новая дата следующей поверки появилась в ЛЭРСе. И если ее нет, то очищать дату поверки и потом разбираться, почему даты нет. Иначе придется объяснять всем, в том числе кому это не нужно, почему нет поверки.

Вне ЛЭРСа обычно с поверкой разбирались просто: весной-летом поверяли, к отопительному сезону приводили в порядок реестр, если обнаруживались отклонения.

Т.е. текущий подход породил еще одна операция по обслуживанию поверки в ЛЭРС Учете и добавил новую, несвойственную ответственность сотрудникам, отвечающим за поверку.

И я не могу однозначно рекомендовать вести поверку в ЛЭРСе предприятиям, в которых ЛЭРСом пользуются разные подразделения. Много минусов, не очевидных появилось. В MS Excel точно спокойнее и возможно не сильно сложнее.

Я не связывал никакие вещи, я пытаюсь понять одну вещь. Если за поверками не следят и они приводят к неверному состоянию, зачем их вообще заносить в систему?

То есть, если сотрудник, отвечающий за поверку, должен следить за поверкой, это для него несвойственно?

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

За поверками следят, в своем режиме. Поверки заносят не оперативно. А при текущем алгоритме расчета состояния ее нужно заносить оперативно. И это требование не тех.процесса предприятия, а только ПО. И это очень не хорошо.

Столкнулся еще с одной стороной текущего алгоритма расчета состояния.

Используем ЛЭРС для контроля внутренних контуров СО, ГВС и ХВС. Данные по вводу берутся с УКУТ. В этой же системе сроки поверок на УКУТ прописаны.

Один из рабочих экранов диспетчера - карта с объектами. Для учетной записи диспетчера в расчете состояния отобраны только те НС, которые касаются его. И диспетчера не должны касаться проблемы поверки и допуска.

Получается нельзя использовать карту для диспетчера, раз к НС добавляются лишняя для него информация. Тогда что использовать?

Повторюсь :slight_smile: Не мое дело и не ваше дело настраивать тех.процессы клиента. Тем более, если они работают.

Контроль за поверками у всех настроен так или иначе. В связи с возможностью работы синхронизации ЛЭРСа с Аршином я соблазнил :slight_smile: часть клиентов контролировать поверку в ЛЭРСе. Но спустя сезон оказалось поверка требует много внимания, периодически “ломает” диагностику, и, более того, в сроки поверки погрузили пользователей, которым это не нужно.

Видимо Вы не поняли меня. Напишу иначе. Фраза:
Вы связали 3 параллельные, не пересекающиеся вещи в одной и они мешают друг другу.

О том, что в состоянии объекта собрана информация о 3 вещах:

  • нештатные ситуации, которые определяет ЛЭРС Учет;
  • наличие действующей поверки;
  • наличие действующего допуска.

То, что вы их собрали вместе - хорошо. Более того, гибкость при расчете состояния на основе НС - тоже отлично.

Но этой гибкости не хватает при расчете состояния на основе наличия действующих поверок и допуска.

Текущая жесткость схемы мешают при некоторых применениях ЛЭРСа. Где именно, я писал выше в теме

1 лайк

Я писал, что не нашел этого и привел скриншот. Это доступно в будущих версиях?

В 3.57 точно доступно. В 3.56 такие записи не всегда попадали в журнал.

Хорошо. Правда это никак не влияет на предложения.

Раз вы отказываетесь от предложения. Значит придется какие-то костыли придумывать. Еще не знаю как, обойти это ограничение. Но использовать синхронизацию с Аршином будут меньше, как следствие продлять подписку будет меньше причин у небольших систем. Значит пока так