Open APIs

Yes, this is certainly a problem.  It was a mistake made in the beginning of the Open API project and the subject of issue AP-2130, which was first reported in 2020, however despite much discussion by subject matter experts no action was taken and recently it was closed due to inactivity.

In the TM Forum Information model (SID) it is of type long integer however even there the description incorrectly referred to it as a float however that error was fixed with FX-1033 in 2021.

It is a common mistake made by many developers to map the decimal notation of monetary amounts to a float type in a programming language. I guess I don't have to explain the problem to you though @Darshan Mhatre as you've clearly experienced it, for others ask your CFO if he likes the sound of "arbitrary precision arithmetic". :)

Now it can be argued that there is nothing wrong with the current representation in Open APIs as the encoding is JSON which is all text.  So it is up to the receiver to know how to map the characters 7178.9955 to an internal data type however the problem is that you, and everyone else, is relying on a library which implement a CODEC function to do that mapping and it is very likely that a JSON number with a decimal in it will be automatically decoded to a floating point number (float).

My recommendation in AP-2130 was to use integers for the value digits and exponent separately, which is how it is done in 3GPP TS 32.296 and IETF RFC8506, something like this: 

// one dollar
"unitCost": {
   "valueDigits": 1
}
 
// $1.42
"unitCost": {
   "valueDigits": 142,
   "exponent": -2
}
 
// one thousandth of a cent
"unitCost": {
   "valueDigits": 1,
   "exponent": -5
}

The simplest thing you can do is just ignore the specifications and put your monetary value in as a string (e.g. "7178.9955"). This is what we do in SigScale OCS.  Our client implementations always send decimal monetary amounts as strings and our server implementations happily accept that and represent it internally as an integer value in units of millionths of a cent. Our server implementations also accept floats, as decoded by the JSON CODEC library, to remain conformant with the specifications. Our implementations prefer JSON number representation whenever there is no decimal. So the only potential problem left is when a non-SigScale client consumes our monetary values, here we chose fiscal responsibility over conformance. ;)

------------------------------
Vance Shipley
SigScale
------------------------------