Community

The Field Value is Ambiguous: integer or real. (Error)

Avatar
Written by Permanently deleted user
  • 4

I have a number field that is unable to have more than 2 decimals.  This is the following customization I have for the field:

Data Type: Number
Language: English
Content Settings: General
Any Value, Allow more than 2 digits in fractional part

There are no rules, or custom actions on the field.  I have tried adding a normalization to be able to allow it to have up to 4 decimal places but this also doesn't work.

Does anyone know how to fix this?

An example would be a number like 1.089 or 2.7654

Thanks!


Was this article helpful?

0 out of 0 found this helpful

Comments

4 comments

Sort by Date Votes
  • Avatar
    Permanently deleted user

    This is could be the result of three places after the decimal and the types of separators you are allowing with normalization.  "1.089" COULD be "One Point Zero Eight Nine" or it COULD be "One Thousand and Eighty Nine".  In other words the software can't distinguish one possibility from the other and so it warns you about it.  If you can't overcome it by changing your normalization settings; specifically the "Digit Grouping Symbol" and the "Decimal Symbol", then the only other option is to try and address it with script/code which can get tricky. 

    0
  • Avatar
    Permanently deleted user

    Thanks!  I will play around with this, I had a feeling it was due to the normalization.  Will let you know what I come up with.


    0
  • Avatar
    Jeremy Burgess

    Two routes to try:

    • In an autocorrect script you can use a RegeEx to see if your number follows the pattern \d+\.\d{3} and, if so, append with another zero. 1.234 becomes 1.2340 which is then unambiguous.
    • On the field properties, 'Data' tab, edit the settings for the 'Number' data type that you are almost certainly using. Look out for the setting "Resolve separator ambiguity according to field regional settings" (and make sure that your regional settings are also set).
    0
  • Avatar
    Permanently deleted user

    We tried the "add an extra zero" route and that only worked for one possible separator/number format.  The project I'm involved with deals with invoices from all over the world.  Just sticking an extra zero on there resulted in occasional incorrect interpretations.  1.234 on an invoice from France for example could legitimately be one thousand and thirty four.  Yes it would usually clear the ambiguity warning but the exported result was not always correct.  Point being, it depends what your project looks like; that might work but it depends. 

    We ended up doing a check on a portion of the invoice lines and depending on how the math works out, we then chose the correct interpretation and applied that to all lines.  We found the regional settings were also hit and miss as I believe that simply uses the vendor country, but unfortunately for us vendor country doesn't always determine the correct format.

    Best of luck

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post