AVEVA™ PI System™ Feedback Portal

Welcome to our feedback site!


We created this site to hear your enhancement ideas, suggestions and feedback about AVEVA products and services. All of the feedback you share here is monitored and reviewed by the AVEVA product managers.

To start, take a look at the ideas in the list below and VOTE for your favorite ideas submitted by other users. POST your own idea if it hasn’t been suggested yet. Include COMMENTS and share relevant business case details that will help our product team get more information on the suggestion. Please note that your ideas and comments are visible to all other users.


This page is for feedback specifically for AVEVA PI System. For links to our other feedback portals, please see the tab RESOURCES below.

Add a new idea Subscribe
Status Completed
Product AVEVA™ PI Server
Categories Asset Framework (AF)
Created by Matt Voll
Created on Aug 19, 2022

RELATED IDEAS

too many UOM Classes

it becomes increasingly difficult/unreasonable to keep adding more and more UOM classes when a large majority of them only contain one or two UOM's. The list of UOM classes is getting quite large. It would be more helpful to have another choice for UOM's that are needed but will not necessarily be used for any conversions. One possible idea being a UOM class that can be marked/forced to be unconvertable . . . a Misc. UOM Class. pH is a good example of a UOM class that has to be created that for all practical purposes only has one UOM and would never be converted to anything else.
  • ADMIN RESPONSE
    Aug 19, 2022
    We strive to provide a basic set of UOM classes that we felt would be useful for our general customer base. We also understand that each user has different needs, which is why users can provide their onw UOM class based on their needs. This request seems to fit that model in that you can add a UOM class for your specific needs.
  • Attach files
  • Guest
    Reply
    |     Aug 19, 2022
    This makes a lot of sense. I frequenly create UoMs with only one Unit in the Class, without requiring conversion, just to make the unit explicit and avoid confusion. This might also help to create UoMs that are inherently not suited for conversion, like /month or /year units.