У ЗАО «Термико» уникальность номеров изделий реализована только внутри каждой модификации. В одном типе СИ может быть несколько модификаций. Например, в типе 46156-10 их пять: КТПТР-01, КТПТР-03, КТПТР-06, КТПТР-07 и КТПТР-08. В результате в Аршине появляются такие записи.
Уверен, что не только ЗАО «Термико» выпускает под одним типом СИ несколько модификаций и при этом не обеспечивает уникальность номеров изделий по всему типу.
Я не нашел способа ограничить поиск экземпляра оборудоания по модификациям при синхронизации с Аршином. Если действительно такой возможности нет, предлагаю рассмотреть добавление функции поиска экземпляра оборудования с учетом модификации.при синхронизации с АРШИН
В моделях оборудования уже можно определять варианты исполнения. В том числе, варианты можно задавать для системных моделей оборудования. Это на случай если мы какой-то вариант исполнения пропустили. У варианта есть поле “Наименование”, по которому можно провести поиск.
Если после поиска в АРШИН найдено несколько результатов для устройства, мы дополнительно отфильтруем их по наименованию модификации. Найдём - отлично. Если же не найдём, всё так же выберем первую запись из найденных, но допишем в системный журнал информацию
Для устройства {device} найдено несколько результатов поверки, выбрано первое совпадение {resultId}.
Если такой вариант подходит, можем включить в 3.63. Тесты показывают, что найти таким образом вполне можно.
В системный журнал мало, туда, те кто отвечает за поверки не смотрят. Нужно до них нонести информацию. Возможно через предупреждение, через НС, у вас уже есть такоеи связанные с поверкой.
Эта тема возникла когда применилась “чужая” поверка к неповеренному прибору, прибор не поверили и попытались сдать узел
Добавьте вручную к системной модели, это можно сделать.
А нужно смотреть. В системном журнале сейчас протоколируется множество событий, которые связаны с синхронизацией поверок. Отправлять часть в журналы, а часть в НС неправильно.
Это придётся сделать каждому администратору в каждой администрируемой системе. Решение рабочее, но далеко не каждый так глубоко погружен в тонкости работы с системой.
Моё мнение: это должно работать сразу после чистой установки, вероятно ВЗЛЕТ ТСРВ не единственный пример подобной ситуации.
Нет смысла просить сотрудников, отвечающих за поверки, смотреть системный журнал — там для них мало значимых сообщений. Это не эффективно и малорезультативно. Это всё равно что завести общий почтовый ящик на весь дом и предлагать всем жильцам искать там свою корреспонденцию.
В системе уже реализованы уведомления о критических НС — их можно получать в Telegram и на почту. Может быть, стоит выделять сообщения о поверках и также отправлять их адресатам через отдельные каналы оповещения?
В любом случае работать не будет, так как придётся задавать вариант исполнения. Даже если мы добавим системные, для ТСРВ он необязательный, так что не факт, что его зададут.
В системном журнале сейчас пишутся достаточно много событий, связанных с синхронизацией поверок в АРШИН. Размазывать их по разным механизмам я считаю неправильным. Тем более заносить эту информацию в нештатные ситуации.
Системный журнал можно отфильтровать, чтобы отобразить только события источника “Синхронизация результата поверки”, так что малозначимые сообщения убрать легко.
Этот способ не рабочий. Вот список причин, почему:
Нарушение принципов проактивности: современные системы должны активно информировать пользователей о важных событиях, а не заставлять их искать информацию.
Превышение когнитивной нагрузки: пользователи могут одновременно обрабатывать 5-9 единиц информации. Системный журнал содержит гораздо больше. Фильтрация кардинально не меняет ситуацию.
Усложнение : вы заставляете пользователя думать там, где это не нужно. Поиск информации в системном журнале требует дополнительных когнитивных усилий.
Проблемы с объёмом и релевантностью данных: в системных журналах очень много технической информации, не относящейся к задачам конкретного пользователя. Это пугает пользователей, и это не шутка.
Неадаптированная подача информации: изложение событий в системном журнале часто не адаптировано под обычного пользователя, занимающегося поверками.
Неэффективность рутинных операций: регулярный просмотр системного журнала создаёт дополнительную рутину, которая «пожирает время».
Низкая оперативность: пользователи не узнают о критических событиях немедленно, что может привести к серьёзным последствиям.
Снижение доверия: неудобный пользовательский опыт снижает доверие как к синхронизации, так и к ЛЭРС Учёт в целом.
Увеличение обращений в поддержку: если пользователи не получают нужную информацию автоматически, они чаще обращаются за помощью.
Перекладывание ответственности: такой способ перекладывает ответственность с системы на пользователя в вопросе, который он плохо контролирует.
Достаточно?
При этом я не предлагал делать сообщения о синхронизации с АРШИН нештатными ситуациями. Используйте уже имеющиеся каналы для информирования пользователей о событиях синхронизации.
Если такой механизм не будет реализован, нам придётся создавать собственное решение, что приведёт к дополнительным затратам и постоянному сопровождению кода при переходах между версиями.
Честно говоря, похоже на выкладку нейросети, которая реально с этим никогда не работала и написала чисто теоретические причины. Большинство пунктов спорные, но спорить с AI не слишком хочется.
Я против того, чтобы эти уведомления попадали в нештатные ситуаций. Это не нештатная ситуация. Это вспомогательный механизм, который раньше всегда вёлся вручную. Почему раз в неделю нельзя посмотреть отфильтрованный системный журнал, чтобы понять как проводится синхронизация и где есть проблемы?
Такая информация в теории может отправляться в центр уведомлений в раздел “поверки”, но никак не в нештатные ситуации.
