Comments
We are using many decimal calculated fields which are supposed to be percentages, but they are numbers. From the perspective of our users, we've identified an issue with how percentage columns are currently handled in Microsoft. When they export data to Excel, these columns appear as numeric values. This creates a problem because users can't easily change the format to a percentage, which is essential for accurate calculations. In our project, we rely heavily on fields that calculate percentages. Unfortunately, Dynamics 365 lacks a dedicated percentage data type. As a result, when these percentage-calculating fields are included in the views and the users are exporting the data to Excel, they face challenges in performing calculations due to Excel's inability to automatically format these values as percentages. To improve the user experience and productivity, it would be beneficial for Microsoft to consider introducing a new data type, possibly as a subtype of the Number data type, specifically designed for handling percentages. This enhancement would empower our users to work more effectively with percentage data in their Excel exports.
In the out-of-the-box Dynamics 365 views, there is an ambiguity regarding the information presented on the left side of the interface, specifically whether it represents the number of pages or the number of entries. This ambiguity leads to confusion, especially since on the right side, there is an option to navigate to the next page.
Furthermore, when using editable grids, only the current page number is displayed, with no indication of the total number of available pages. This lack of information regarding the pagination structure further complicates the user experience.
To enhance user clarity and consistency, it would greatly benefit our users to establish a consistent and uniform presentation of the number of pages throughout the Dynamics 365 interface.
In road transportation (ADR), HatMat divisions (also called classification code) are not unique, especially for classes 2-9
- For class 1 the divisions, also used as compatibility group are unique. 34 divisions, 1.1A to 1.6N
- For classes 2-9, there are 188 classification codes, from which 7 of them are existing in more than 1 class. These classification codes determine the unit (litre/kg) for the ADR points calculation. Example: Code F in class 3 is liquid goods, same code F in class 4.1 is solid goods.
Hence, from ADR perspective it is a but to have the division unique, it is only unique together with the class ID.
Could you explain the use case, why it was made unique, while the UI rather assumes the division and class together to be relevant for this table.
hope you can fix this asap. thanks.