1.CRM在Insert数据到DB的时候，对时间类型的字段进行了转零时区的操作（对于中国，也就是做了-8H的操作，例如：CreateDate:2013-3-6，但存储在数据库的值是：2013-3-5 16:00:00）。
2.CRM在把时间类型的字段值显示到Page的时候，进行了转当前时区的操作（对于中国，也就是做了+8H的操作，同上：数据库存储的2013-3-5 16:00:00，显示到控件也就是2013-3-6）。
因此，在Plug-in里面获取时间字段的值，进行处理的时候（比如赋值到其他实体或其他字段），需进行toLocalTime()操作，再赋值。这样会避免被赋值字段Insert到DB时候，CRM会自动再转零时区，而出现错误。（实例：通过Plug-in获取到的CreateDate是2013-3-5 16:00:00，如果你直接赋值到UpdateDate，它存储到数据库时会变成2013-3-5 8:00:00，而显示到Page就成了2013-3-5 16:00:00）
获取当前时间应该用DateTime.Now，是中国时区的时间。
比如： Sql 查询: DATEADD(HOUR,8,ph.CreatedOn) as CreateDate在基础上加8个小时
说明这个8不要写死，因为在中国是加8个小时，在其他地方就可能不是加8个小时, 这里可以用DATEDIFF(HOUR, GETUTCDATE(),GETDATE())代替8。
另外报表查询的时候，如果是查询的是Filtered实体名 ，则时间字段不需要加8个小时；如果查询的是表或视图，则时间字段需要加8个小时。
sql 修改: DATEADD(HOUR,-8,GETUTCDATE()), 在基础上减去8个小时
sql 金额保留小数后两位： CAST(pd.new_amount as decimal(20,2)) as TotalAmount
以后对时间的处理，在ＳＱＬ中使用以下函数：
dbo.fn_LocalTimeToUTC() 将时间转为ＵＴＣ时间。
dbo.fn_UTCToLocalTime() 将时间转为本地时间。
这两个函数是ＣＲＭ库里带的，在另的地方用不了。
在.NET里使用.ToLocalTime()。
不要用8小时来做增减。
如果按8小时来计算，以后做跨国的CRM项目时就会出问题。时间在中国对了，到日本、巴西就错了。
报表中做时间类型比对的时候，要dbo.fn_UTCToLocalTime() ，再比对，这样我的报表都要修改
那个函数性能不好，按我说的，尽量是用来修正参数时间，而不是拿去做查询用。
select dbo.fn_UTCToLocalTime(ABC)
和 where dbo.fn_UTCToLocalTime(ABC) 〉'xxx'
的不要用。