Agree with Vance
and while not looking this specific TMF spec. I look from the bidding/quoting point of view the way prices should be represented accurately in a localized manner including translations, formatting ( ',.' , amount of leading zeros, decimals etc), rounding, units, divisors in the units linked with the actual amount (and alike) and by taking care that the actual "price variables" are not hardcoded to e.g. relational datamodels. Defining prices via proper normalized variable definitions is fundamentally different from the hardcoding prices to datamodels which you see in many applications, causing challenges especially with the usage pay as you go type values.
Also it should be noted that certain document generators can be toggled to handle numbers as strings, but in-case the precision is lost during jogging the data to-and-from json, then it is nearly impossible to find out where the precision was lost.
Is there in TMF a specification which handles the challenges json format has - on principle level?
While json is not strongly typed, the actual data should be stored in strongly typed manner also from the variable definition point of view. Integrations should share and obey the same definitions for variables, or it will fail by design.
.. and have to say ... not sure this is defined anywhere but having "price wrong in the bill/invoice" is different from the "charge is wrong in the bill/invoice" do we e.g. make difference between these. Meaning where the price is 0,004 €/min and charge is 4 € due amount of min = 1000.
Having those values in broken in json, makes things hard.
rgrds Paavo
------------------------------
Paavo Muranen
Telia Company
------------------------------
Original Message:
Sent: Mar 16, 2020 02:07
From: Vance Shipley
Subject: TMF677_Usage_Consumption, Quantity precision loss
While decimal notation is the common form of representing monetary amounts actual floats must never be used in accounting. You should consider an amount of $0.99 USD to be 99 cents. If you need fractional cents you must choose an acceptable precision and deal internally with the monetary values as an integer number of those units. For example with a unit of millionths of a cent $0.99 = 99000000.
So technically it's not a problem, you just have to do the conversion appropriately. Now the problem you may encounter is that you have a JSON CODEC library which converts a JSON number in decimal to a float type automatically. Here you have two solutions: 1) use a different CODEC; 2) use a string to represent the value.
It is my opinion that the base type Common/Money.schema.json should be changed to use type string as it is NEVER appropriate to use a float to represent money!
------------------------------
Vance Shipley
SigScale
Original Message:
Sent: Mar 13, 2020 04:16
From: Péter Radics
Subject: TMF677_Usage_Consumption, Quantity precision loss
Hello,
We're mapping data consumption from our OCS system to TMF677 API, but the API specifies the Quantity as a float value, which results in precision loss when dealing with data usage amounts that are measured in bytes in the OCS system.
What is the TMF recommendation to overcome this issue?
- should we extend Quantity with another field for extended-precision value?
- should we just change the TMF spec and remove the "float" format specifier (or change it to "double")
- should we just convert the value to MB or GB and live with the precision loss (right now the API is only used for customer-facing display purposes, so this could be a valid option, but I feel that this is not really a good solution given that the API might be later consumed by other services that may need exact amounts without precision loss, like charging or promotion engines)
The "float" type is used in other places (like Money) as well, where it is probably not the best approach either due to the possible rounding errors and precision loss... Is it valid TMF usage to ignore these format specifiers where we think it's detrimental to the API?
Thanks for the help,
regards,
peter
------------------------------
Péter Radics
Vodafone
------------------------------