SuiteScript开发中辨别环境

问题 如何设计程序可以在正式环境刷新沙盒后不会导致涉及接口的逻辑出现两个环境的混乱 解决方案 在开发时使用runtime.accountId进行逻辑判断,如果是正式环境则runtime.accountId是1234567这样的account ID,如果是测试环境则会包含沙盒的编号比如1234567_SB1。 对于向外发送请求的情况,可以针对环境不同设置不同的URL,这样正式环境的代码刷新到沙盒也不会导致沙盒请求外部系统的正式环境。

Record.removeCurrentSublistSubrecord()是Dynamic模式下修改inventorydetail的良药吗

故障 更改Item Receipt的时候需要涉及quantity更新的情况,此时Inventory Detail和Quantity两个字段互相羁绊,先改哪个都会导致另一个字段验证错误。其他土办法比如itemreceive=false,或者置空location字段都在UI上可以实现效果,但是在脚本中都会造成inventory detail quantity错误。 问题 以下哪一个办法是良药: 结论 Record.removeCurrentSublistSubrecord()不会引发inventory detail quantity must be x的错误,但是会导致unexpected error。 这种情况是由于isDynamic: true造成的,使用dynamic mode则会永无天日,使用standard mode你会平安落地。

用N/cache保存token用于发送http请求的MapReduce/Scheduled脚本

前情提要 某些NetSuite向外部系统推送数据的场景可能需要用到MapReduce的场景,此种情况如果涉及token是比较多变的。如果放在getInputData阶段取得token然后用参数带给map阶段使用,则可能随时遇到token过时的情况,可能还需要重新获得token;如果是每一步都重新获得token则可能消耗目标系统太多资源。中国很多集成实际上是采用了IP黑白名单制度,然而这种方式并不适合NetSuite这样的云平台。因此使用OAuth2.0这样token机制是必要的而用N/cache更使这样的情况变得便捷。 代码设计 使用N/cache构建如下的代码,可以实现向目标主机获取cookie然后使用cookie内容发送请求的目的。 其中getCookieToCache的方法如下。注意Cache.get()的loader返回值如果是json则系统会帮你stringify。 之后使用时,直接调取cacheObj.get()就好,如果cache因为过期、系统自动抛弃等原因不存在,系统会自动按照loader去获取。 延伸阅读

NetSuite错误: USER_ERROR: The transaction date you specified is not within the date range of your accounting period.

错误描述 保存单据时发生错误,信息如下: 对不起,您指定的事务处理日期不在会计期间的日期范围内。 The transaction date you specified is not within the date range of your accounting period. 原因 在 NetSuite 中,有一个名为“允许交易日期超出过账期”的偏好设置,它决定系统如何处理日期和期间不一致的交易。如果该偏好设置为“禁止”,并且交易日期超出当前过账期(例如:日期 = 2022年5月31日,期间 = 2022年6月),则会发生此错误。NetSuite 不允许您保存这样的交易。 解决方案 针对此同步错误有两种潜在解决方案: 编辑 NetSuite 中的偏好设置,允许交易日期超出过账期: 在 BILL 中打开出现同步错误的交易

无法创建客户存款,提示您为以下字段输入一个无效的字段值 123:customer

症状 假设客户的内部id是123。在脚本中无法创建客户存款,提示您为以下字段输入一个无效的字段值 123:customer。手动在页面用suitescript用customer id赋值123可以显示但是无法保存。手动选择或者搜索则无法显示该客户 解决 如果UI和script的系统表现是一致的,则更多去考虑这个问题出自某个系统设置。 进而在consolidated payment中找到系统启动了consolidated payment,在Setup > Accounting > Preferences > Accounting Preferences中找到Apply Payments Through Top-Level Customer Only这个选项被选中。如果这个选项被选中,则客户存款只能从最高级的母客户进行创建。

Scheduled和Map/Reduce类型脚本重复创建记录或者逻辑重复运行

症状 事务处理类型或者自定义类型的单据在Scheduled或者Map/Reduce类型的脚本背景下被重复创建,重复创建的时间可能非常接近,在同1分钟或几分钟以内。 分析过程 查看是否Scheduled和MapReduce类型脚本存在ondemand类型的唤起,这种情况可能是有该脚本自身以ondemand类型唤起,也可能是来自suitelet或者userevent类型的脚本唤起。 ondemand的唤起在部署资源充足的情况下可能在很短时间通过task.submit()被唤起多次,每次唤起通过search获得相同的数据,用相同的逻辑处理,因此重复创建记录可能就发生在同一分钟。 解决办法 最有效的办法是限制ondemand运行,只留一个not scheduled的脚本部署,确保只有一个实例在运行。如果同时也有定时运行的实例,务必移动到上班时间之外,避免ondemand触发和定时触发同时取数。