How to POST attribute values of type Real or Currency?

[thrinn]

I am struggling to write back some values to attributes of type Real or Currency. What happens is:

In the IMatch Attribute Panel numeric attributes are formatted according to the user's locale settings. I am in Germany, so for a Currency attribute I get e.g. "5,50 EUR", for a Real attribute "8,00".
When I use v1/attributes GET the values are returned with decimal points instead of commas and without the currency, which makes perfectly sense:

Code Select Expand


   "Price": "5.500000",
   "Tax Rate": "8.000000",

This is fine because JavaScript, as all other programming languages I know, uses a decimal point.

But when I POST these values back (with v1/attributes POST), I get wrong values because "5.500000" is interpreted as "5500000". You can try that out easily using the Attributes sample app. It does work when I use a decimal comma instead: "5,500000" is interpreted as "5,5".

This poses different problems:
- First, I would expect I could use the same format returned by attributes GET to change values using POST. Everything else is not consistent.
- Second, if this is Locale dependent: How do I get the current user's Locale? And how do I convert the values back and forth?

Before I invest more time trying to find some useful JavaScript library to handle this, I just want to ask if this behaviour is intended?

[Mario]

Are you sending your data as strings or numbers?
Show me the POST body of your request.

[thrinn]

Code Select Expand

set:Calculation
id:31
tasks:[{"data":{"Description":"Pictures","Quantity":"5","Price":"5.50","Tax Rate":"8.00","Tax Amount":"2.20","Total":"27.50","Grand Total":"29.70"},"op":"update","instanceid":[1]}]


The values are sent as text. So maybe this is the reason?

[thrinn]

I tried to send the values as numbers. The POST request looks like:

Code Select Expand

set:Calculation
id:31
tasks:[{"data":{"Description":"Pictures","Quantity":10,"Price":1.5,"Tax Rate":8,"Tax Amount":1.2,"Total":15,"Grand Total":16.2},"op":"update","instanceid":[1]}]

But then I get even bigger numbers, for example 1500000 instead of 1.5. See screenshot.

As said before, only using decimal comma and POSTing strings works. See Price attribute in screenshot 2 with the correct result, while Tax Amount is 100x the input value.

Code Select Expand

set:Calculation
id:31
tasks:[{"data":{"Description":"Pictures","Quantity":"10","Price":"1,5","Tax Rate":"8.00","Tax Amount":"1.20","Total":"15.00","Grand Total":"16.20"},"op":"update","instanceid":[1]}]

[Mario]

When you send strings to update a numeric Attribute:

- the JSON parser will detect that it is not a number but a string.
- It will hand over the string to the Attribute input processing of the IMatch engine.
- when the engine received a string value for a numeric property, it transforms them using the locale (country/language/numeric settings) of the current user. Basically this is what happens if you type in a number in the Attribute panel. This means you need to specify the floating point number in the correct format.

This may probably be changed, but it requires many deep changes in the Attribute processing. Add a FR if you need this so I can allocate a sufficiently large time slot. Or maybe look at a work-around for IMWS first.

The "too big" values are of type currently. IMatch stores currently values internally scaled by 10,000 to get the required four digit precision. Maybe there is a problem withi communication there. Need to check.

[Mario]

I have changed the parser in IMWS. It now expects Attribute data in floating point format (Real or Currency) with a decimal point (the same format it returns).
I have updated the Codes & Recipes tutorial with a section that explains the expected input formats and the returned formats:

Search for "Attribute Data Format" in the Code Recipes and Tips document.

[thrinn]

Thank you, Mario. I think it is more logical this way, if GET and POST use the same format. And it spares some hazzle in the code. (Well, at least in MY code, maybe it is more complicated in the IMatch code now  ).

And once, superb support: Which other company changes their internal code base just to make life easier for some poor developers in the wild? 

[Mario]

This only covers the case where you send strings:

{
"MyCurrency" : "123.45"
...
}

Sending a number

{
"MyCurrency" : 123.45
...
}

is a different thing, and more precise of course.