Forum Stats

  • 3,733,796 Users
  • 2,246,820 Discussions


Project in dutch language, but use a point as decimal separator (not comma)

717861 Member Posts: 11
I am working with Haley v9.4.1.71.
I am preparing a demo for coming wednesday in which I want Haleys to work together with Siebel. I have now ran in to a problem for which I can’t find the solution. I have made the rules in the Dutch language wich all works fine. As it seems it also uses the dutch format for numbers, this means that the decimal separator is a comma instead of a point. Siebel however, requires the decimal separator to be a (point).
Data delivered from Haleys to Siebel is in the current situation therefore converted incorrectly.

My question is:
How can I keep the dutch language, but use the point as a decimal separator (instead of the comma).

Thing I have tried already:
- Configure the file with the Haley Interactive Configuration Tool
The ‘Application Output Numeric Format’ is #,###,###,##0.###############
This looks correct, but still in the User Interface the comma is used as the decimal separator.
- Set the Windows Regional and Language Options (Tab Regional Options) to English(United States) and customized the Decimal symbol to a point.
- I have also looked in the Folder C:\Program Files\Haley\Office Rules 2008\Language\Dutch but couldn’t find specific settings for the comma separator

I hope you can help me solve this issue.

Sake Kampen


  • Brad Tuckett-Oracle
    Brad Tuckett-Oracle Moderator Posts: 638 Employee
    My advice is to use Oracle Policy Automation 10.0 which is now available through Oracle E-Delivery.

    Brad Tuckett, Intelligent Advisor team

  • 717861
    717861 Member Posts: 11
    edited December 2009
    Thank you for the reply.

    The problem to upgrading to v10 is that we make use of a OPA <-> Siebel integration developed by the local Dutch Oracle pre-sales team. And I don't know if we can replicate what Oracle has done for us if we upgrade.

    But the problem I'm having doesnt lie with the connection but with OPA itself, in OPA the decimal separator is a comma where I want it to be a point. This problem only exists when I create a Dutch project, when I create an English project (on the same windows environment with the same regional settings) the decimal separator is a point.

    I have advanced a little bit, but I’m not quite there yet.
    Haleys seems to use the Regional settings of Windows.

    The regional settings of my Windows-installation was English, so I temporarily went to Dutch to see what the settings were there. Ofcourse the numberformatting was in the dutch way with a comma as the decimal separator. So I changed this to a point and clicked ‘Apply’. Then I changed the language back to English and clicked ‘Apply’.
    In Haleys the same error persisted.

    So I went back to the regional settings of windows, and there I went back to dutch (English was still selected) and saw to my surprise that the ‘corrected’ decimal separator for dutch was set back to its default.

    So I changed it again to a point and now kept the dutch regional setting, and tested Haleys again. The behaviour of Haleys then changed. But surprisingly the decimal signs are now deleted.
    a value derived from a table in excel is transformed as follows
    in Excel: 28.5 ==> in Haleys: 285
    Provided by user in Haleys: 543.1234 ==> shown in Haleys summary screen 5.431.234
    I can provide decimal numbers and they seem to be accepted, but if I show them in the summary screen (using the%%) I see that every number is rounded to a whole one in the way described above.

    Are you certain this is a known issue that has been adressed in Haleys 10?
  • Davin Fifield-Oracle
    Davin Fifield-Oracle Member, Moderator Posts: 1,032 Employee
    There have indeed been several issues with handling of regional settings fixed in OPA 10. This sounds like one of them.

    You can install OPA 10 side-by-side with OPA 9.4, so you can test if 10.0 works as expected without uninstalling 9.4.

    As for the Siebel integration - I'd recommend looking at the OPA Connector for Siebel. Since the 9.4.2 version was released earlier this year, installation has been simplified, and data mapping from Siebel to OPA data model is now included via a Mapping UI in Siebel. An even more recent version is now also available in version 10.0.0.
  • 717861
    717861 Member Posts: 11
    I used the OPA <-> Siebel integration that was developed by the local Dutch Oracle pre-sales team, and not the OPA Connector for Siebel product. This solution doesnt work (yet) with OPA 10. But I will test OPA 10 in the near future.

    For the demo we managed to create a workaround with the help of the dutch oracle pre-sales team. The numbers exported from OPA where changed using a javascript:

    function CleanNumber(numOPA) {
    /* this function expects something from OPA like 543321,1234 or 54.321,1234 (Dutch format), which it will turn into 54321.12345 */
    numOPA = numOPA.replace(/\./,""); // remove thousand separator
    numOPA = numOPA.replace(/,/,"."); // replace decimal separator
    return numOPA;

    This did the trick for now. In the future we will probably work with version 10 and then it wont be an issue anymore.

    Thank you for your help.
This discussion has been closed.