Добавление статуса узла учёта [3525]

Здравствуйте.

Возможно ли добавить в ЛЭРС учёт отображения статуса и времени сдачи узла учёта в эксплуатацию/вывод узла учёта из эксплуатации и срыв пломбы.

Это необходимо для своевременного реагирования и возможности вести всю информацию в одной программе.

Подобный функционал обсуждался здесь Отображение текущего состояния узла учета и еще тема была, помоему реализация заявлена уже

Спасибо за информацию.

В ближайших планах я увидел:
Версия 3.07 R12 (3 апреля 2015)

  • журнал работ по объекту учета

Это то, о чем мы говорим или же для данного функционала есть отдельный срок добавления ?

В журнале работ по объекту учета можно будет фиксировать все работы, которые проводились на объекте: ремонт оборудования, настройка, профилактический осмотр, перевод на летний/зимний режимы, замена приборов и т.д.

Примерный список полей журнала:

  • Объект учета
  • Точка учета
  • Дату начала работ
  • Причина
  • Выполненные работы
  • Результат работ
  • Исполнитель
  • Проверяющий
  • Результат проверки

А что касается поверки ? Когда будет реализовано?

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

В одной теме мы обсуждаем только один вопрос. В этой теме мы обсуждаем статус узла учёта, его связь с вводом/выводом из эксплуатации и срывом пломбы из вашего первого сообщения.

Я бы просил разработчиков вернуться к появлению статуса точки учета.
Причем 2 параметров.

  1. статус - для обозначения состояния узлов учета
  2. допуск - определения наличия допуска в коммерческий учет.

Список статусов актуальный для меня следующий:

  • нет записи;
  • затоплен;
  • разграблен;
  • сорвана пломба;
  • заполнен (только для объектов, при наличии разных статусов в точках учета объекта).

Список значений допусков актуальный для меня следующий:

  • дата до который допущен узел учета;
  • нет допуска (в случае объектов если хотя бы одна точка учета не допущена;
  • допуск (только для объектов, при допуска у всех точек учета).

Эта информация сейчас часто пишется в параметре “комментарии”. А на этот параметр (комментарии) и так много информации которую приходится там размещать.

Статус и допуск должен назначаться также, как назначается летний/зимний режим работы узла. Быть доступным для групповых операций для назначения и снятия.

Список статусов должен быть доступен в справочниках для редактирования. Хотя, так как уже много справочников, то может имеет смысл группировать справочники по смыслу с использованием закладок (но это offtopic).

Отображаться оба параметра (статус и допуск) должны на списке точек учета и объектов. В том числе в строке точки учета на закладке объекты учета при раскрытии объекта.

Меня интересует, можно ли ожидать реализацию описанного? и в каком объеме

Жду реакции

Ждем реакции :slight_smile:

Пока поддержка статусов объектов запланирована на версию R26. Вопрос по допускам для нас так же актуален, и мы ведём проработку возможных вариантов решения. Скорее всего, после обсуждения мы поставим реализацию в планы на версию R25.

К написанному выше, хочу добавить, что статусы и допуски следует, на мой взгляд, задавать не заходя в формы редактирования точки учета или объекта. Пользователи, управляющие статусами, не должны иметь права на редактирование точек учета и объектов

Поясните пожалуйста почему…

хм…
Это все применимо к системам, где либо много объектов, либо много пользователей. Редактировать объекты, точки должны 1, максимум 2 пользователя. Т.к. во-первых описание элементов в ЛЭРС Учете далеко не совсем простое, и чем сложнее система, тем больше нюансов. Если все имеют право вносить изменения, то постоянно происходят изменения, которые не добавляют устойчивости системы. Не понимаю, почему я это описываю. :-): Вроде очевидная вещь :ze_va_et:
А во вторых, слишком много кликов для для того, чтобы просто поменять статус. Операция должна быть простая и не должна требовать много времени.

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

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

Получается, что право на редактирование объекта должно включать право на изменение статуса, верно?

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

Угу. Не спорю.

Я писал, что это два разных разрешения.

Тут Вам решать как сделать с наименьшими затратами. Меня устроит и:

  • полностью независимые эти два разрешения;
  • введение приоритетов; только если их не было, то вопрос вроде не глобальный чтобы делать такие нововведения;
  • связанность прав на уровне интерфейса настройки, т.е. разрешение редактировать статус, визуально однозначно будет показывать, что добавятся права на редактирование объекта и точки учета; например как при установке компонентов для windows server.

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

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

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

Вариант с приоритетами не подходит, т.к. это меняет всю модель безопасности. Запрет всегда должен иметь приоритет над разрешением.

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

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

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

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

Этот вопрос должен у Вас вылежаться? Как долго стоит ждать?