问题
计算定义公式的值并填写到指定列round( 3025 * 0.033, 2)，算出来的结果是99.82，应该是99.83才对
重现问题
1. 找个单据，加2个小数字段，2个文本字段。
2. 给 文本1 字段配个值更新事件，方便触发。计算两个小数字段相乘并四舍五入保留2位小数，结果填入 文本a 字段。如下图：
3. 进入运行时，新建一张单据，给两个小数字段分别填入3025、0.033，然后随便改一下 文本1 字段的值触发事件，计算结果为 99.83。
计算一下看是否正确：
Python2的round函数是四舍五入，所以应该是99.83，正确。
4. 然后保存单据，关闭再打开，修改一下 文本1 字段触发事件，计算结果为99.82。这就不对了。
5. 再试试，修改3025为3000，修改一下 文本1 字段触发事件。然后再改回3025，然后再修改一下 文本1 字段触发事件，计算结果为99.83。看一下http数据：
可见传去服务端的是3025.0。
6. 关掉再打开单据，看看打开单据时服务端传来的值是多少：
可见服务端的值是3025.0000000000。这是因为数据库字段是decimal(23,10)，所以数据库中存的就是这个。
7. 那么，问题就变成了，为什么3025.0000000000算出来就是99.82。
排查
1. BOS处理python表达式用的是第三方组件IronPython (2.6.10920.0)，写个测试程序看看，代码如下：
简单地调IronPython，计算round( a * b, 2)的值。
运行结果：
可见，当3025后面有10个小数0时，计算结果99.82，不正确。当后面有8个小数0时，或没有0时，计算结果99.83，正确。多试几种情况发现，小数的位数为9、10时，结果为99.82，不正确。小数的位数为0-8时，结果为99.83，正确。而且结果类型是double。
2. 再把代码中的表达式改为a*b，看看运行结果：
都是99.825后面若干个0，结果类型是decimal。
3. 再改一下，直接计算round(a,2)：
可见，99.82500000000000000000 四舍五入出来就是99.82，不正确。当少3个小数0后，99.82500000000000000四舍五入出来就是99.83，正确。
4. 考虑到round函数结果变成了double，可以大胆推测一下，IronPython计算round时，将传入的decimal转为double，再调用C#的Math.Round，最终返回了double类型的值。
写个代码验证一下，看看decimal的99.82500000000000000000转double后四舍五入结果是多少：
断点调试看一看：
可见decimal的99.82500000000000000000转double后变成了99.824999999999989，那么四舍五入自然就变成了99.82。
少3个0的99.82500000000000000计算是正确的。
5. 那么问题就找到了。decimal的两个10位小数相乘，结果的小数变成20位。IronPython计算表达式的round函数，会先将decimal转为double，由于double的精度问题，此时可能出现误差，最终造成结果不准确。
变通解决方案
由于python对decimal的支持需要引入decimal模块，在单行的表达式中显然不行。double类型又确实有精度问题。所以可以考虑用变通方案：
1． 写个插件处理，直接对decimal数值使用Math.Round，注意要传MidpointRounding.AwayFromZero才是四舍五入，否则是四舍六入五成双。这种方法最完美，就是稍显麻烦。
2． 既然小数位数太多可能有精度问题，那就根据业务需求减少小数位数，毕竟需要支持10位小数的业务也不多。在设计单据时，小数字段精度调低一些，不要用默认的10位。注意在保存单据之后再修改精度，是不会修改数据库字段的精度的。所以这只适合新开发的单据，或者自己去改数据库字段精度。
3． 仍然考虑减少小数位数。比如例子中的3025，业务上最多只会有2位小数，例子中的0.033最多只会有4位小数，那么表达式这样写：
F_MOB_Text =round( round( F_MOB_Decimal, 2) * round( F_Jac_Decimal, 4) ,2)
这样先减少无效小数位数再计算，精度问题会少一些。
