Hi all,
Anyone here have experience with Polish Zloty?
I am trying to input some numbers as: 725,70
but regardless of the number format i select it gives me the wrong format. E.G: 72,570.00
If anyone has feedback that would be greatly appreciated. Thanks!
@rmehta I have played with them but still no luck. Will keep playing around and will report if there seems to be a bug.
Thanks
Hi all,
I am back trying to fix this problem again but I am still having troubles.
Attached is a snippet of an invoice I received for office supplies in Poland. You can see the format on the Invoice. When I enter this data into ERPNext, it changes the format and gives me the wrong number.
Invoice
ERPNext
The format seems to be this: # ###,## though when I select that I don’t get the correct results.
Thanks!
Hi all,
Still having these issues. Please view the gif attached to see what I am talking about. This is becoming an issue for us to use…not sure what to do.
I am trying to create an expense for 252,75 Polish Zloty. But it keeps changing the currency to 25 275,00 which is very incorrect.
Thank you!
If you type “123.45”, does it enter correctly? Wondering if the input format (using , instead of . ) is an issue rather than the display format.
I had similar issues with ‘.’ and ‘,’ as decimal separator… Use ‘,’ and it should work (or, at least, that was the case for me) 
Changing it from , to . worked and formatted correctly!
Thanks guys, seems like a bug that should be sorted out, but for now this work around is great.
Much appreciated 
Not sure it’s a bug in ERPNext. I had the same issues with Odoo (ups! I named it 
). Depending on your locale (and keyboard) settings the ‘.’ on the numeric keypad is interpreted as ‘.’ and therefore not used as a decimal separator but simply ignored.
Maybe someone here with more experience can shed some light on tweaking system settings for this to work correctly…
Hmm interesting. No idea if the locale does anything. I am in the U.S. on an american keyboard, but have been doing work in Poland lately so having the zloty sorted out would be helpful moving forward. Maybe its a python issue? Either way good job narrowing down the actual problem. Thought I was losing my mind
I don’t think it’s the keyboard/locale - my guess is that (@rmehta you can correct me if i’m wrong!) Frappe takes in the number as a float with some kind of stdin (i.e. 12.34) and uses a period to determine where the decimal lies.
If there are characters other than digits and one period, then it chops everything off to the right of the first non-digit non-period character (i.e. 1234y31 == 1234,321 == 1234) and then upon exiting the field it re-formats to the number format.
Try it out - enter 123b4 and you’ll see the result as 123. Same thing if you do 123,4 or 123,45 or 123xhaif and so on.
In order to fix it, whatever takes in the input would need to be re-written to use the decimal separator from the specified number format.
I completely agree, my guess is it’s the input type being a float which is maybe causing the issues. Would switching to a string work better in this instance? I am also not a true expert on this.
What a great community we have here!
Well the input type is always string (so what I said above isn’t quite the case) - but taking the string and casting it to a float is where the translation issue is happening.
In my case I’m using #.###,## as my Number format.
If, in any “money” field, I enter:
12,3 → ERPNext “reads” $12,30 (CORRECT!)12.3 → ERPNext “reads” $123,0 (ignores the ‘.’)12b3 → ERPNext “reads” $12,0 (chops everything after “weird” character ‘b’)Such behaviour would not be an issue, since in my country using ‘,’ as the decimal separator is the right thing to do, and I would expect anyone to do otherwise.
The problem is that, when using numeric keyboard, the decimal separator character is written ‘.’ (unlike e.g. MS Excel, which “translates” it to ‘,’) and then ERPNext ignores it.
That’s why @DrTrills gets those huge numbers, I believe 