Skip to Main Content
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.

Status Declined
Created by Guest
Created on Aug 19, 2022

Request for multiple abbreviations per UOM

request for UOM to have option for multiple abbreviations without the need to create many duplicate UOM entries. Example for tonne, the system abbreviation is t, there should be an option to add mt (metric tonne, to differentiate between US ton) etc. The different abbreviations reference the same UOM.
  • ADMIN RESPONSE
    Aug 19, 2022
    Thank you very much for sharing your feedback on the PI Server. After further evaluation, we have decided to decline this item, as we are not planning on implementing it in the near future due to other high priority items across the PI System. Thank you for your feedback, and know that we are listening and reviewing every item that gets submitted!
  • Attach files
  • Guest
    Reply
    |
    Aug 19, 2022
    I just came up with a great reason to want this: localized UoM abbreviations. Instead of going the distance of localization of AF, this could provide a way to define localized UoM's. So for e.g. kg/h we could define kg/std for use in german applications.
  • Guest
    Reply
    |
    Aug 19, 2022
    Not really a big fan (hey, don't blame me, i'm an engineer in europe), but one cannot deny that the real world does not fit into a neat SI-unit system. So an upvote from me.
  • Guest
    Reply
    |
    Aug 19, 2022
    I just came up with a great reason to want this: localized UoM abbreviations. Instead of going the distance of localization of AF, this could provide a way to define localized UoM's. So for e.g. kg/h we could define kg/std for use in german applications.
  • Guest
    Reply
    |
    Aug 19, 2022
    If there were multiple UOMs abbreviations, applications may accept them, but they would all be displayed using the same standard abbreviation. Roger, your use case of using in different locales would not apply, unless we also added locale information to each abbreviation. The complexity there is likely unwarranted.
  • Guest
    Reply
    |
    Aug 19, 2022
    In response to Chris Manhard, "If there were multiple UOMs abbreviation..." Well, not really sure if it's unwarranted, but complexities don't add up, complexities multiply so i get your point. It's still doable though, the tricky part here is that for number and date formatting, this functionality is typically available in the frameworks used, but UoM's is just to much of an odd-ball to have in frameworks so that brings this to the application, and then the complexity is there do deal with. This is a real case i have to deal with, and currently i need to resort to defining localized UoM's and/or push the logic to the front-end (e.g. PI Vision custom symbols). But that does not apply to all user-facing applications, so i'ts just a partial solution which i don't like. Just wanted to add a good reason why this is a requirement in the real world. Not really saying this would be top-of-list in regards to development investment versus value...