There is a problem with using the decimal point (Settings are Swiss German): When entering a new invoice and the unit price is entered (e.g. 76.14) it get’s correctly translated into the total (Betrag). After saving tough, it’s not saved correctly into the Database, but as 7614.00.
You apparently have the comma set up as the decimal separator. Check the regional settings in your operating system, and check the preferences in Manager. Make sure they’re both set to use the point as the decimal separator. Dollar to a donut, they’re not.
Operating System has dot as a decimal point. In the preferences of Manager, it shows the comma. Now, afaik, you can only set the region by name, but not explicitely the decimal point in manager. Or am I wrong?
Nevertheless I would consider filing this as a bug, as it’s behaving correctly on screen but not when saving down. So the behaviour is incoherent.
You must set Manager and the operating system to the same number and date formats. If you don’t, then the operating system accepts the input in one format and then Manager tries to interpret it the other way. That’s not a bug, it’s user error. It’s like if Johann and Ivan are having a conversation, and Johann thinks they’re speaking German and Ivan things they’re speaking Russian; Johann keeps saying “ja” and thinks he’s being very agreeable, but Ivan thinks Johann is very full of himself.
Manager assumes that German-speaking Swiss users will want to use the comma decimal separator. If you want to use a decimal point, then set Manager to a country that uses the combinations of date and number formats that you want (try UK English) but keep the language as Schweizerdeutsch. I don’t believe setting the formats to another region will have any other effect on the program. (@Tut or @Lubos, can you confirm?)
@Anooky, when you issue invoices to customers, do you want them to see dot or comma as decimal separator?
Sorry, I don’t know for sure.
@lubos: Decimal.
@Jon: My Operating System is set to Switzerland and Manager is also set to Switzerland, as you can see from the screenshot - so it is definetely no user error but rather Manager saying it’s expection Swiss German but really expecting Russian to stick to your example. Decimal IS the standard in Switzerland - nobody uses Komma. Your suggested solution to set to UK would have impacts on the date format as well which is different between UK and Switzerland. Also if there is a Option to set “Switzerland” it should behave correctly. Also you can see in the first screen shot, Manager actually interprets it correctly on the screen from 76.14 to 76,14. Only when it saves it to the DB, it saves it as 7’614, so there is a problem when saving to the DB in Manager.
Okay, @Anooky, on further research I now see your point. 
But it’s not strictly a “bug” – it’s a misunderstanding of the unusual way Switzerland displays its decimals.
First, let’s clear up one thing: “Decimal separator” can mean either a point (.) or a comma (,) depending on the location. The word “decimal” refers to the base-10 number system, not to the notation, and “decimal separator” refers to the concept of the mark that separates units from fractions, not to the specific typographic convention. Some countries (mostly English-speaking countries and Southeast Asian countries) use the decimal point. while the rest of the world uses the decimal comma.
Switzerland is unusual in that it apparently uses the point when expressing currency but the comma for everything else. Is that correct, @Anooky? Does the practice vary between German-speaking cantons and French/Italian/Romansh-speaking ones?
@Lubos, at a minimum, it would seem that Switzerland should be switched from comma to dot, if @Anooky confirms that that is indeed the country-wide local practice. Given the vagaries of point-versus-comma, and given also that personal preference might vary, perhaps it would be better if Manager had the user choose the date and number formats directly instead of selecting a region. You’d pick decimal comma vs point, thousands point vs comma vs raised tick vs space, standard vs Indian digit grouping, date separator dot vs slash vs hyphen, DDMMYYYY vs MMDDYYYY vs DDMMYY vs MMDDYY vs YYYYMMDD, etc. Or perhaps there can be a regional setting with the option to override a particular behaviour, as there is in Windows.
As a possible temporary fix, try the Romansh (Switzerland) settings in Manager. You’ll get the decimal point, the raised-tick thousands separator that you seem to prefer based on the example you gave in your last posting (1’123’567.89), and DD/MM/YYYY dates. If that’s not the combination you want, try poking around in the many country/language options in Manager and see if there’s one that comes closer to what you want.
@Jon,
Glad we are kind of getting on the same page 
– to make things worse, Rumantsch is defined wrongly as well. The date format is defined as DD-MM-YYYY but should be DD.MM.YYYY.
[cid:image002.jpg@01D1FCC1.401B8C90]
«Poking around» is quite a cycle, it would be easier, if you gave me a combination as I assume you know the details. I’d need: 1’234’543.40 for Numbers and 24.10.1975 as a date format.
Have a great day,
Martin
Really the only way to come up with the combination you want is to poke around. There isn’t a table of all the formats, AFAIK, unless @Lubos has one. That’s why I made the suggestion I did, that the number and date formats should be configurable independently, rather than only by pre-defined regional settings.
1 Like
I don’t have one because these regional settings are extracted from the underlying operating system.
So that’s really bizarre, @Lubos. If the regional settings come from the underlying OS, then why does @Anooky report that he has both Manager and Windows set to DE-CH, but the treatment of numbers is different? And why does he report that the date separator that Manager uses for RM-CH is different to what Windows uses?
(I’ve checked in the Windows Region and Language settings, and I can confirm what @Anooky said. German (Switzerland) does indeed come up as dd.MM.yyyy and 123'456'789.00 in Windows, but not in Manager.)
That’s not what I see. The settings on my computer in OS for German (Switzerland) are consistent with what Manager shows.
Okay, so this is quite odd. I could swear that Manager was using the comma as a decimal separator for German (Switzerland) when I first started trying to help @Anooky, and his screenshot in the 3rd posting in this thread confirms that. When I looked in Manager just now, however, the separator is the point.
Hmmm…
I’ll leave @Anooky and you to it, if he still has the problem.
I suspect his operating system has , in settings and that is what Manager is showing. He didn’t show screenshot from his operating system, only screenshot in Manager. So there is no proof of discrepancy.
hi - anooky 's sysadmin here. I believe I can shed at least some light into this.
When @Anooky says his operating system is configured to use the comma he probably means his client accessing the manager web interface. However, the server is actually hosted on a ubuntu linux server, running manager.io with mono.
I think it does not matter what the OS locale is set to (why would manager.io provide an option to change the locale settings if it enforced the OS system locale anyway ) , but to make sure I changed the system’s default locale from en-US to de-CH. As expected, this did not change the output in manager.io.
Now for the fun part. I wrote a little program to test if mono somehow provides wrong formatting info to the application. The program checks the system locale first (to make sure mono really sees de-CH by default) and it also prints out the values for a different locale (de-DE) to compare:
using System;
using System.Globalization;
public class Example
{
private static void testCulture(double myvalue, CultureInfo culture)
{
Console.WriteLine("Culture Name: {0}", culture.Name);
Console.WriteLine("DecimalSeparator: {0}", culture.NumberFormat.CurrencyDecimalSeparator);
Console.WriteLine("Number format: {0}", myvalue.ToString("N",culture));
Console.WriteLine("Currency format: {0}", myvalue.ToString("C",culture));
Console.WriteLine("");
}
public static void Main()
{
CultureInfo culture;
double myvalue = 4213376.14;
culture = CultureInfo.CurrentCulture;
testCulture(myvalue, culture);
culture = new CultureInfo("de-DE");
testCulture(myvalue, culture);
}
}
The output is really is…uhm… interesting:
mcs numberformat.cs && mono numberformat.exe
Culture Name: de-CH
DecimalSeparator: .
Number format: 4'213'376,14
Currency format: CHF 4?213?376.14
Culture Name: de-DE
DecimalSeparator: ,
Number format: 4.213.376,14
Currency format: 4.213.376,14 ?
If you format the de-CH value as Number it prints correct group separators but the wrong decimal separator. If you format it as Currency it get’s the decimal separator right but f**cks up the group separator.
So it seems at least part of the problem apparently can be blamed on mono doing weird things. OTOH I think even if manager.io gets the wrong separator info this should never cause the database to store the wrong values. I’d suggest it should treat the input value as invalid (“I’m expecting a comma but you’re sending me a dot!”). From @Anooky 's OP it seems like manager.io ignored the “unknown” separator and 76.14 became 7614.
2 Likes
Thanks @gryphius, I’m actually impressed you knew where exactly to look for the issue.
It seems like the solution is to let users specify their date and number format manually and drop the ability to select “culture” from operating system.
2 Likes
@lubos Thanks lubos. Having said that, also please let me mention that we love your product and your big efforts you’re putting into it. It’s has an amazing feature set and we very much appreicate that you have a fair pricing that let’s small companies like us use it. Big Thank you for your effort, guys!
