我们必须认清一个事实，NetSuite Saved Search是一个被封装化的SQL查询工具。在NetSuite的早期版本中，可以利用Formula字段做很多SQL语句上的灰色应用。但是慢慢的，灰色应用范围被压缩了。目前只剩下一个“.id”的应用了。
今朝我们就谈谈.id的用法，以及其背后的逻辑。
在我们早前的一篇文章中，提到过某些字段会基于不同的语言环境在Search结果中返回不同的值。这样的话，会造成错误。
NetSuite 交易记录类型中文环境下的失效_毛岩喆的博客-CSDN博客这是个新手常犯的错误，因为在做Transaction的Saved Search时，有个陷阱字段就是Type字段。这个字段会跟随系统语言而呈现“中英文”的数值。那么就意味着我们今后在写跟“记录类型”相关的Saved Search的Formula时，需要选择Record Type字段，而非Type字段。在数据字典上，可以看到Type字段类型为Select，而另外一个Record Type字段的类型为Text。在英文环境中写的Saved Search运行的好好的，但是在中文状态下失效了。https://blog.csdn.net/remottshanghai/article/details/127341817?spm=1001.2014.3001.5501近期，我们发现.id能够更加彻底的解决这个语言环境导致的意外问题。
举个例子，在一个Transaction Search中，我们想在结果字段中用Account Type来作为条件，格式化结果。类似于：
case when {accounttype}='Other Current Liability' then '正确' else '错误' end但是发现问题来了。因为Account Type在不同的语言环境下的字符串，例如在中文环境下字符串是“其他流动负债”。那么，我们的公式将不得不改为：
case when {accounttype}='Other Current Liability' or {accounttype}='其他流动负债' then '正确' else '错误' end但是，如果有法文用户呢，德文用户呢？
所以，这不是个办法。
NetSuite留的.id就发挥作用了。
作为Formula中的灰色应用，用户可以在公式中的基本上任何字段中增加.id作为结果输出的加强，这时输出的就是这个字段的内部ID值。这个ID值通常为整型或者原生英文的字段串。不会因为语言环境而改变。从而解决我们上面面临的问题。
这个ID值其实是在数据库中某个字段所关联（Join）表中的id字段的值。举个例子。
Account会Join一个表叫做Account Type，在这个表中是有个字段真的叫做ID的。
这个Account Type表的ID字段为String类型。我们拉取其中的值看一下。
其值为原生的英文字符串。这些字符串是我们真正需要的值。
因此，上面的公式改为如下内容，行不行？
case when {accounttype.id}='OthCurrLiab' then '正确' else '错误' end答案是：
不行！
我前面提过“某个字段所关联（Join）表中的id字段的值”。如果{accounttype}字段没有关联任何表，所以你是取不出id字段的值的。虽然系统不报错，但是你就是取不出。我们需要做个变通，将公式改为{account.type.id}，也就是取Account这个关联表的Type关联表的ID字段的值。有点绕哈：）
case when {account.type.id}='OthCurrLiab' then '正确' else '错误' end这样就可以了么？
答案再次是：
不行！
按照这种方式取出的值，有可能会有些异常，以上面为例，在Search结果中的字段上会出现“表达式错误”的话，记得格式化一下字符串（如果ID是String类型的话）。这是很诡异的情况，原因不明，反正这样做对了。
case when to_char({account.type.id})='OthCurrLiab' then '正确' else '错误' end下面是实验数据，自己操练一下吧。
DECODE({account.type.id},'OthCurrLiab','流动负债','其他类型')
case when to_char({account.type.id})='OthCurrLiab' then '流动负债' else '其他类型' end
//请注意case when中 to_char的使用。不是多余，你去掉试试。但是用decode就运行正常，奇了个怪。
如果有任何关于NetSuite的问题，欢迎来谈。我的邮箱：rick.mao@truston.group
