Let's have a look (and wonder) at the various ways in which quantities are displayed across various SAP TM screens, with respect to decimals places.
Start with the item list in Forwarding Order UI...
... then check out the list of items of a related Freight Unit:
and finally the Air Booking containing the freight unit:
The weight of the item has no decimals in FWO, but two in FU (when expressed in KG), or even three in Booking (but expressed in TO - the unit of measurement for volume in that particular booking). Notice also the difference between the display of remaining capacity and consumed capacity.
The volume is also interesting: for the first FWO item, it has four decimals in FWO screen, but three (and the value is rounded) in FU screen. Whereas the Booked Capacity (Volume) has two.
A good start in the investigation would be the fact that the display of quantities (= defined in data dictionary as based on data type QUAN, and which require a "reference field" for unit of measurements) can be influenced by a setting in SAP Basis transaction CUNI (which is a collection of customizing settings, actually):
However, SAP Basis exhibits a rather unpleasant behaviour. When the value to be displayed has more decimals than specified in UoM customizing, then all decimals - as defined in the underlying domain - are used up.
This is usually not a problem, but TM uses for quantities a domain, /SCMTMS/QUANTITY, which has 14 (yes, fourteen) decimals.
As such, assuming a setting like above, a value of "1 KG" is displayed as "1,00 KG", a value of "1,5 KG" is displayed as "1,50 KG" as desired, but a value of "1,555 KG" is painted on the screen as "1,55500000000000 KG".
Additionally, SAP Basis delivers customizing for most used units of measurements, but without reasonable display settings. For many - if not all - units, the number of decimals is left empty, which is interpreted as "zero". As a consequence, any value that is not a full integer carries the whole list of decimals from domain.
This might have not stand out so much in "classic ERP", where quantitiy-related domains are usually short, but as said TM uses 14 decimals in its data model. Thus, when using standard CUNI setting, one would get such gems:
To avoid this, various groups of TM developers, with or without knowledge of CUNI, started looking for alternatives, and in the end two concurrent approaches for UI emerged (persistence is not affected):
1. A domain with only three decimals - /SCMTMS/UI_QUANTITY
2. A domain with full number of decimals, but a conversion exit that removes all irrelevant zeroes (and as such ignores the CUNI settings) - /SCMTMS/UI_QUANT_RND. The conversion exit, developed in TM, is called QTYRN.
The first alternative can be seen in the list of items in FU screen (the second screenshot above), as well as in Air Booking (the third picture) - but only as Total Booked Capacity and Consumed Capacity, whereas the other one is active in the list of items in FWO screen, as well as in the Air Booking - for Remaining Capacity. We can see that these alternatives are applied inconsistently even inside the same screen.
For the unit of measurements pictured above, CUNI settings in the relevant system are:
KG - two decimals
M3 - two decimals
TO - three decimals
Knowing that, we can explain why each value looks like it does:
the weight of "1500 KG" is displayed as "1.500,00 KG" in FU screen, based on CUNI setting, whereas in FWO screen the conversion exits cuts all irrelevant decimals and thus we get "1.500 KG"
the volume of "7,1257 M³" exceeds the number of decimals from CUNI, therefore we should have normally seen "7,12570000000000 M3". But none of the screenshots above uses the standard backend domain. Instead, in FWO screen the conversion exit eliminates the zeroes, whereas in the FU screen the value is rounded to the three decimals of /SCMTMS/UI_QUANTITY.
The usage of the shortened domain is dangerous, though. It is suited for read-only fields (as the potential loss of precision is not so important -> the persisted values keep the higher precision) but can actually hurt in „modifying” screens, as the user cannot enter a very detailed value, and might even alter inadvertently the persisted data.
For instance, if the user modifies the volume of FU item to a different value, and wants to revert the change, he/she can only type the "original" value from the input field - "7,126 M3". But the document is saved with an actual change.
The shortened domain is useful however in read-only lists like the ones employed in transportation cockpit, since the decimal separator is stable. The domains with fourteen decimals (with, or without conversion exit) are not usable - for such use-cases the minimal loss of precision weigh far less than the improvement brought by a stable separator. For an "bad" example like below, it is difficult to quickly add up the values (to obtain a rough order of magnitude):
So what now?
Well, it's time we TM developers cleaned up the mess.
First, the shortened domain must be banished from modifiable screens
Then the additional domain /SCMTMS/UI_QUANT_RND must either be retired and replaced with the standard domain /SCMTMS/QUANTITY, or used consistently across all screens
And, lastly, a decision must be made whether the domain that is picked as UI-relevant (be it /SCMTMS/QUANTITY, or /SCMTMS/UI_QUANT_RND, as per decision above) will employ by default the conversion exit QTYRN or not.
if yes, then the customer who dislike it and want to return to a CUNI-based control have the choice to remove it from the domain
if not, then the customers who appreciated the lack of irrelevant zeros have the choice of attaching QTYRN to the domain
Update - 14.02.2017:
SAP Note 2426219 delivers the harmonization of quantity display. We decided to retire /SCMTMS/UI_QUANT_RND and to attach the conversion exit QTYRN to domain /SCMTMS/QUANTITY. Due to the large number of manual steps, we recommend to wait for the corresponding Support Packages (SAPK-14006INSAPTM for release 9.3 and SAPK-15003INSAPTM for release 9.4).
SAP Note 2426220 contains the advice to remove the conversion exit from the affected domains, in case the CUNI-based control mechanism is desired.