Your question seems to have been cut off - but here are some points to consider:
- Monarch settings are based on input files - rather than user/system settings
- Assuming the input files for the different users follow the same format (i.e. fields are in the same location), and are just localized somehow (e.g. commas/periods as separators), you'd need to avoid using commas and periods as traps.
- What are the inputs being used? How do they differ from each other?
I have a model created with numeric fields.
The report being used (prn file) sometimes has the period (.) as the decimal separator, and sometimes has the comma depending on the user. SE users use a comma, UK users used a period. We initially set their settings within Monarch (Classic) as per this.
I have created the models, and my format is UK. However, when the SE users use the models I have created, their settings change to be UK rather than SE.
This means there is a problem because their prn file uses the comma, and they have to go back in a change the settings. I want to fix the settings as per USER and not change it when using a model. This would mean the same model can be used for both UK users and SE users.
Note. I have not used the decimal place in the traps. Its the settings that are the issue, the templates work fine.
Although I haven't tried this, maybe you can extract your numeric data as character first and create a calculated field that converts it to a number using the following:
Str(,) - to remove spaces between numbers
Replace(,,) - to replace comma separator with a period
Val() - to convert string to number
An IF() formula is also needed to determine the format of your numeric fields in the input files.
Is there a way to determine the format of numbers in the report so that we can use that in IF() formula?
How about dates? Do you need to determine if the date is DMY vs MDY?
Hope this helps.
A similar suggestion to Mela's would be strip the decimal and thousand separator then divide by 100 (assuming the report is always two decimals)?
If your original field is a character field called [MyChar], the following will work:
If the report can vary in number of decimals, you'd have to use some additional logic to find the decimal separator position. But I'm not sure how you would handle 123,456 as this could be 123'point'456 or 123'thousand'456.