Не нашел как:
- отключить НС из-за просроченной поверки
- исключить НС из-за просроченной поверки из расчета состояния объектов для конкретной учетной записи
1 лайк
У нас нет нештатных ситуаций о просроченной поверке. Поясните подробнее что вы имеете в виду.
Мне нужно управлять статусом объекта. Если поверку не ведут в ЛЭРСе, а только заведены приборы, то получается такая картина
Мне нужно исключить эту информацию о просроченной поверки из расчета состояния объектов для конкретной учетной записи.
Если поверку не ведут, почему не очистить параметр “Дата следующей поверки”? Тогда она не учитывается в состоянии для расчёта.
Кстати, очистить можно групповой операцией со списка объектов. Выбрать флажками нужные объекты, нажать кнопку “Редактировать” и оставить пустым поле “Дата следующей поверки”.
А зачем уничтожать информацию? Она была заполнена, но не актуализирована пока. Эта информация осознано хранится в ЛЭРСе
Мешает статус объекта. В текущем положении не получается пользоваться диагностикой, т.к. статус у объектов, где НС и где просрочена поверка одинаковый.
Предложение поддерживаю. Возможность настроить влияние на расчет статуса объекта для определенной учетной записи нас тоже интересует.
Необходимость ровно такая же, как описал @Kvashnin
Как минимум потому, что она уже устарела и приводит к подобным нежелательным эффектам. Я не совсем понимаю зачем её хранить. Это поле предназначено именно для того, чтобы отслеживать актуальность поверок. Если вы их не отслеживаете, предалагаю данные удалить.
Я прошу сделать возможность исключить состояние поверки из расчета состояния объектов для пользователей.
Вы же предлагаете мне сделать выбор:
- хранить только актуальную информацию о поверке
- удалить данные о поверке всех устройств и отказаться от использования ЛЭРСа в качестве хранения данных о поверке
Для меня это разные вопросы. Не понимаю, почему Вы их объединяете.
Данные о поверке не актуализируются по разным организационным причинам. Вы сейчас сформировали новое требование к использованию Вашего ПО.
Сейчас как только поверка заканчивается - состояние статуса меняет свой смысл. Он уже не отражает привычную для пользователя информацию, а делает его красным. Хотя до этого красный цвет говорил о наличии вполне определенных НС, связанных с режимами и объемом потребления и работой оборудования.
При этом статус, с настроенными вручную НС, используется и на мнемосхемах с картами и просто картах. При окончании поверки в точке, используемой на мнемосхеме, смысл мнемосхемы меняется. А мнемосхемы обычно не должны содержать информацию поверке
Т.е. ваш подход ломает использование статуса на мнемосхемах и картах.
Кроме того, мне не понятно, почему я могу настроить какие НС отображать в статусе для конкретного пользователя, но не могу отключить использование данных о поверке.
Т.е. Вы допускаете, что не всем пользователям нужны все виды НС, но настаиваете, чтобы все пользователи видели информацию о поверке.
Хм…
1 лайк
Да, предлагаю сделать так. Со вторым пунктом не совсем согласен. Это уже не данные о поверке, это неактуальная информация, которая используется для оперативного контроля. Данные о том, что устройство когда-то было поверено есть в истории оборудования.
Статус это не только наличие нештатных ситуаций. Это более общий параметр, который объединяет НС, работы, поверки, он так задумывался изначально. Никаких противоречий я тут не вижу.
Нет не меняется, с чего бы?
Проблема в том, что вы считаете статус статусом НС, но на самом деле это не так.
не вижу этого
Вы назвали, то что обсуждали другими словами и решили, что это аргумент
Я пытался вам донести свое мнение о том, что когда вы сделали управляемым список НС которые влияют на расчет состояния, Вы дали в руки удобный инструмент, который показывает пользователям на проблемные точки/объекты. При этом проблемами для разных пользователей являются разные события.
Просроченная поверка явилась причиной, по которой я обратил внимание на негибкость состояния в отношении поверки, и, вы подсказали, допуска.
Как ведется учет поверки и допуска, на мой взгляд, не должно влиять на маркировку объектов, если пользователю не нужно знать про эти вопросы. Возможно вы не учитываете, что показания с узлов учета используются для технологических целей, в этом случае пользователи не хотят видеть “лишние” для них данные.
Еще пример. Часто НС по температурному графику выделяют отдельным пользователям и этим пользователям, часто не важна поверка, про допуск не знаю.
Как я написал выше, вы сделали состояние гибким в отношении НС, но почему-то негибким в отношении допуска и поверки. И я тут вижу противоречия.
У вас 2 неточности в статье, на которую ссылаетесь:
-
по док-ции поверка не используется для расчета состояния
-
для предупреждения зачем-то придуман термин “некритические нештатные ситуации”, который вроде больше не используется и приходится искать, о чем идет речь
Пока я всё ещё не вижу проблемы в том, чтобы убрать дату поверки в случае если они не используются. Тем более, что эти параметры в таком случае показывают некорректные данные.
Предложение мы добавим в копилку идей, но пока без конкретной версии. В дальнейшем предлагаю вернуться к обсуждению если появится какие-то новые мысли.
Не понял, о каких параметрах речь. Предположу, что о дате поверки.
Вы связали 3 параллельные, не пересекающиеся вещи в одной и они мешают друг другу. Обслуживание поверки в ЛЭРС Учете - трудоемкое дело, до интеграций с Аршином, вообще в большинстве случаев сомнительное из-за высоких трудозатрат на поддержание.
После интеграции с Аршином привлекательность сильно выросла, но нужно проверять результат интеграции периодически. Т.е. этот процесс породил новую операцию, требующую время.
В процессе обсуждения оказалось что, если дата поверки сама не «встала», то нужно оперативно с ней разобраться. Сотрудники отвечающие за поверку должны постоянно контролировать, что новая дата следующей поверки появилась в ЛЭРСе. И если ее нет, то очищать дату поверки и потом разбираться, почему даты нет. Иначе придется объяснять всем, в том числе кому это не нужно, почему нет поверки.
Вне ЛЭРСа обычно с поверкой разбирались просто: весной-летом поверяли, к отопительному сезону приводили в порядок реестр, если обнаруживались отклонения.
Т.е. текущий подход породил еще одна операция по обслуживанию поверки в ЛЭРС Учете и добавил новую, несвойственную ответственность сотрудникам, отвечающим за поверку.
И я не могу однозначно рекомендовать вести поверку в ЛЭРСе предприятиям, в которых ЛЭРСом пользуются разные подразделения. Много минусов, не очевидных появилось. В MS Excel точно спокойнее и возможно не сильно сложнее.
Я не связывал никакие вещи, я пытаюсь понять одну вещь. Если за поверками не следят и они приводят к неверному состоянию, зачем их вообще заносить в систему?
То есть, если сотрудник, отвечающий за поверку, должен следить за поверкой, это для него несвойственно?
Я честно, говоря, от обилия разных предложений начинаю путаться. Но пока моё мнение остаётся неизменным.
За поверками следят, в своем режиме. Поверки заносят не оперативно. А при текущем алгоритме расчета состояния ее нужно заносить оперативно. И это требование не тех.процесса предприятия, а только ПО. И это очень не хорошо.
Столкнулся еще с одной стороной текущего алгоритма расчета состояния.
Используем ЛЭРС для контроля внутренних контуров СО, ГВС и ХВС. Данные по вводу берутся с УКУТ. В этой же системе сроки поверок на УКУТ прописаны.
Один из рабочих экранов диспетчера - карта с объектами. Для учетной записи диспетчера в расчете состояния отобраны только те НС, которые касаются его. И диспетчера не должны касаться проблемы поверки и допуска.
Получается нельзя использовать карту для диспетчера, раз к НС добавляются лишняя для него информация. Тогда что использовать?
Повторюсь Не мое дело и не ваше дело настраивать тех.процессы клиента. Тем более, если они работают.
Контроль за поверками у всех настроен так или иначе. В связи с возможностью работы синхронизации ЛЭРСа с Аршином я соблазнил часть клиентов контролировать поверку в ЛЭРСе. Но спустя сезон оказалось поверка требует много внимания, периодически “ломает” диагностику, и, более того, в сроки поверки погрузили пользователей, которым это не нужно.
1 лайк
Видимо Вы не поняли меня. Напишу иначе. Фраза:
“Вы связали 3 параллельные, не пересекающиеся вещи в одной и они мешают друг другу.”
О том, что в состоянии объекта собрана информация о 3 вещах:
- нештатные ситуации, которые определяет ЛЭРС Учет;
- наличие действующей поверки;
- наличие действующего допуска.
То, что вы их собрали вместе - хорошо. Более того, гибкость при расчете состояния на основе НС - тоже отлично.
Но этой гибкости не хватает при расчете состояния на основе наличия действующих поверок и допуска.
Текущая жесткость схемы мешают при некоторых применениях ЛЭРСа. Где именно, я писал выше в теме
1 лайк
Я писал, что не нашел этого и привел скриншот. Это доступно в будущих версиях?
В 3.57 точно доступно. В 3.56 такие записи не всегда попадали в журнал.
Хорошо. Правда это никак не влияет на предложения.
Раз вы отказываетесь от предложения. Значит придется какие-то костыли придумывать. Еще не знаю как, обойти это ограничение. Но использовать синхронизацию с Аршином будут меньше, как следствие продлять подписку будет меньше причин у небольших систем. Значит пока так
1 лайк
